Multi-threading libraries for .NET

Question

I used multiple threads in a few programs, but still don\'t feel very comfortable about it.

What multi-threading libraries for C#/.NET are out there and which advantages

Answer 1

Please keep in mind that you really should be closing threads (or allowing the threadpool to dispose) when you no longer need them, unless you will need them again soon. The reason I say this is that each thread requires stack memory (usually 1mb), so when you have applications sitting on threads but not using them, you are wasting memory.

For exmaple, Outlook on my machine right now has 20 threads open and is using 0% CPU. That is simply a waste of (a least) 20mb of memory. Word is also using another 10 threads with 0% CPU. 30mb may not seem like much, but what if every application was wasting 10-20 threads?

Again, if you need access to a threadpool on a regular basis then you don't need to close it (creating/destroying threads has an overhead).

Answer 2

There are various reasons for using multiple threads in an application:

• UI responsiveness
• Concurrent operations
• Parallel speedup

The approach one should choose depends on what you're trying to do. For UI responsiveness, consider using BackgroundWorker, for example.

For concurrent operations (e.g. a server: something that doesn't have to be parallel, but probably does need to be concurrent even on a single-core system), consider using the thread pool or, if the tasks are long-lived and you need a lot of them, consider using one thread per task.

If you have a so-called embarrassingly parallel problem that can be easily divided up into small subproblems, consider using a pool of worker threads (as many threads as CPU cores) that pull tasks from a queue. The Microsoft Task Parallel Library (TPL) may help here. If the job can be easily expressed as a monadic stream computation (i.e. with a query in LINQ with work in transformations and aggregations etc.), Parallel LINQ (same link) which runs on top of TPL may help.

There are other approaches, such as Actor-style parallelism as seen in Erlang, which are harder to implement efficiently in .NET because of the lack of a green threading model or means to implement same, such as CLR-supported continuations.

Answer 3

For me the builtin classes of the Framework are more than enough. The Threadpool is odd and lame, but you can write your own easily.

I often used the BackgroundWorker class for Frontends, cause it makes life much easier - invoking is done automatically for the eventhandlers.

I regularly start of threads manually and safe them in an dictionary with a ManualResetEvent to be able to examine who of them has ended already. I use the WaitHandle.WaitAll() Method for this. Problem there is, that WaitHandle.WaitAll does not acceppt Arrays with more than 64 WaitHandles at once.

Answer 4

Check out the Power Threading library.

Answer 5

I have written a lot of threading code in my days, even implemented my own threading pool & dispatcher. A lot of it is documented here:

http://web.archive.org/web/20120708232527/http://devplanet.com/blogs/brianr/default.aspx

Just realize that I wrote these for very specific purposes and tested them in those conditions, and there is no real silver-bullet.

Answer 6

You should take a look at the Concurrency & Coordination Runtime. The CCR can be a little daunting at first as it requires a slightly different mind set. This video has a fairly good job of explanation of its workings...

In my opinion this would be the way to go, and I also hear that it will use the same scheduler as the TPL.