As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What would you suggest as a road map for becoming very proficient in writing multithreaded applications - beyond "tinkering"?
I am a C# developer - would branching off into some other languages help this endeavor?
Does the parallel addition to .NET 4.0 hide things that you should know in order to make it easier?
Read Joe Duffy's "Concurrent Programming on Windows". Joe is an amazing expert.
Investigate different approaches to concurrency on different platforms; look at Erlang, Scala etc
Likewise read Java concurrency books, which will have some subtly different details, but often tackle the same core issues and have some useful patterns. "Java Concurrency in Practice" is often recommended.
Look at the various options on .NET, including the Coordination and Concurrency Runtime and F# asynchronous computations
Definitely learn Parallel Extensions - it'll help a lot, and from what I've seen, a lot of very careful design work has gone into it. (It's changing somewhat for 4.0b2 though, so you may want to defer this for now.)
Theres a really good PDF about threading in .NET here the MSDN documentation for the Thread class as well as the threading primitives (Mutex, WaitHandle, ReaderWriterLockSlim et al) is also good reading.
The key things to understand are:
When to use a thread
When not to use threads
How to manage sharing state between threads.
I could go on to explain these here, but I feel the threading PDF linked to above does a far better job than I could in that respect, the key point is that threads are a powerful tool and understanding when and how to use them will make you more proficient in their use than simply reading MSDN, although strategies for using threads effectively are covered there also.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
A few months back, we introduce Rx into our codebase, and since then the codebase is getting more and more "reactive". I feel that it is really easy to introduce concurrency into the codebase with Rx, as not a single line of "locking" was used yet.
However, I do not understand why it is easy with Rx when I can't explain it in words.
Is it related to the "Actor Model" and "Functional Reactive Programming" concept?
Can someone kindly enlighten me on this please?
I think the main reason it's "easy" is because of the blood, sweat and tears poured into the Rx library by the very smart Dev team behind it at MS.
Look at the (open) source code to see just how much careful code goes into enforcing the Rx grammar and the parameterisation of when and where things run using Schedulers. That has plenty of defensive concurrent code in it. I suggest it's the grammar and Schedulers that bring the simplicity.
Using the model is quite easy, but achieving that simplicity was not trivial. You are benefiting from standing on the shoulders of giants that have hidden the complexity behind a neat and tidy API :)
Incidentally, there is still the odd trap for you to fall into... I'm sure you'll find one sooner or later! One example is that Subject<T>.OnNext() is not protected from concurrent access in Rx 2.x for performance reasons.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I read this question Asynchronous vs Multithreading- is there a difference and search in Google about differences.
What is the benefit to use Asynchronous instead of Multithreading?
and when use Asynchronous instead of Multithreading?
If your task can be done using asynchronous programming, the it is better to do it that way instead of going for multi-threaded programming. for 3 reasons:-
1: Perfomance
In multi-threading, the CPU or w/e has to keep switching between threads. So, even if your thread is doing nothing and just sitting there (or more likely, doing a comparison to see if a condition is true so it can get one with doing with w/e it was created to do), the CPU still switches threads and the process takes some time. I don't think that would be very bad, but your performance surely takes a hit.
2: Simplicity & Brevity
Also, maybe it's just me, but asynchronous programming just seems more natural to me. And before you ask, no, I'm not a fan of JS but still. Not only that, but you run into problems with shared variables and thread-safeness and others — all of which can be side-stepped by using asynchronous programming and callbacks.
3: Annoying implementations of threads
In Python there's this really horrible thing called a GIL (Global Interpreter Lock). Basically, Python doesn't let you actually run concurrent threads. Also, if you're thinking about running a threaded program on a multi-core CPU, forget it.
There might be caveats in C# too, I don't know. These are just my 2 cents...
All that said, asynchronous and multi-threading are really not that comparable. While multi-threading may be used (inefficiently) to implement asynchronousity, it is a way to get concurrency and acynhrounousity is a programming style, like OOP (Object Oriented Programming).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
We are about to implement a small automated securities trader. The trader will be build on top of the excellent quickfix FIX engine.
After due though, we narrowed our options down to implementing it in C# or in Python. Please specify the pros and cons of each language for this task, in term of:
Performance (The fact that Python uses a GIL troubles me in terms of thread concurrency)
Productivity
Scalability (We may need to scale this trader to a fully-sized platform)
EDIT
I've rephrased the question to make it less "C# vs. Python" (which I find irrelevant - both languages have their merits), but I'm simply trying to draw a comparison table before I make the decision.
I like both languages and a think both would be a good choice. The GIL might really be the most important difference. But I'm not sure if it's a problem in your case. The GIL only affects code running in pure Python. I assume that your tool depends more on I/O than on raw number crunching. If your I/O libraries handle the GIL correctly, they can execute concurrent code without problems. And even for number crunching you still have numpy.
My choice would depend on your existing knowledge. If you have experienced C# developers at hand I would go for C#. If you start absolutly from scratch and it's really 50:50, then I would go for Python. It's easier to learn, free and in many cases more productive.
And just to mention it: You might also have a look at IronPython. ;-)
For points "Performance" and "Scalability" I would suggest C# (although a large part of performance depends on your algorithms). Productivity is much of a subjective thing, but now C# has all cool features like lambda, anonymous method, classes etc which makes it much more productive.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Last week I interviewed for a position at a TripleA MMORPG game company here in NE. I didn't get the job but one of the areas that came up during the interview was the about the scalability of the code that you write and how it should be considered early on in the design of your architecture and classes.
Sadly to say I've never thought very much about the scalability of the .NET code that I've written (I work with single user desktop and mobile applications and our major concerns are usually with device memory and rates of data transmission). I'm interested in learning more about writing code that scales up well so it can handle a wide range of remote users in a client server environment, specifically MMORPGs.
Are there any books, web sites, best practices, etc. that could get me started researching this topic?
Here are some places to start:
http://highscalability.com/blog/2010/2/8/how-farmville-scales-to-harvest-75-million-players-a-month.html
http://www.cs.cornell.edu/people/~wmwhite/papers/2009-ICDE-Virtual-Worlds.pdf
In particular, http://highscalability.com is full or articles about huge websites that scale and how they do it (Digg, flickr, facebook, YouTube, ...)
Just one point I'd like to highlight here. Just cache your reads. Work out a proper caching policy where you determine which objects can be cached and for what periods. Having a distributed caching farm will take load off your DB servers, which will greatly benefit performance.
Even just caching some pieces of data for a few seconds - in a very high load multi-user scenario - will provide you with substantial benefit.
If you are looking for physical validation, what I usually find that helps is doing some prototyping. This gives you a good idea usually of any unforeseen problems that might be in your design and just how easy it is to add onto it. I would try to apply any design patterns possible to allow future scalability. Elements of Reusable Object-Oriented Software is a great reference for that. Here are some good examples that show before and after code using design patterns. This can help you visualize how design patterns could make your code more scalable as well. Here is an SO post about specific design patterns for software scalability.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Does anyone have any books written for .net that deal with multithreading? I've looked at Joe Duffy's and Joseph Albahari's books, and they're good. I was hoping however, to have something that also touches on PLINQ and TPL, which Duffy's book certainly does, but many of its examples and snippets are in C++. I was ideally looking for something a little more C# oriented.
Thanks for your suggestions.
Joe Duffy's Concurrent Programming on Windows.
C# 4.0 in a Nutshell hasn't been released yet, but you can access the manuscript online. It covers the PLINQ/TPL libraries.
I strongly suggest, based on his past excellent work, waiting for the second edition of Joe Duffy's seminal Concurrent Programming on Windows if new features in the 4.0 .Net release are what you are after.
Since you are looking for info on an, as yet unreleased, API anything you get now, as opposed to March 2010 is likely to be not quite up to date (or worse will have inaccurate advice - a serious flaw in concurrent programming as small, seemingly trivial aspects can be very important).
To tide you over in the mean time you can read his blog