Discussion: Threading in .NET

Question

I would like to discuss the threading "things" in .NET with you. While other Languages/Frameworks offer a limited clearly defined why how to handle asynchronous calling, there are countless ways to do this in .NET. What I intend to do here, is try to define a kind of "best practice for a given case". In other words: when do you use which treading approach?

Lets start with an enumeration of ways how we can get our code running async:

Thread (new Thread)
ThreadPool (ThreadPool.QueueUserWorkItem)
BackgroundWorker (BackgroundWorker.RunWorkerAsync)
Delegate (Delegate.BeginInvoke)
Task Parallels Library
Parallel Class (Parallel.ForEach)

[Did I forgot any?]

Here is how I decide what type to use:
Thread - usually when i need full control on the thread, e.g. main thread of a sevice.
ThreadPool - short tasks that do not have a high priority - lets say we have an IPC connected to a UI and I just need to losen those calls not to block the UI
BackgroundWorker - UI projects -> Loading/Splash screen
Delegate - usaually only if I need to synchronize with my UI Thread (Dispatcher/Form .Invoke)
Task Parallels Library - not used yet, I guess its a great replacement for "the delegate way" for synchronizing the UI
Parallel - If i need to execute some code for multiple objects - e.g. having a collection of mails from different servers and I need to do something with each of them.

Now its on you, how do you decide what to use when?

If this discussion is going well, i would like to add the Semaphore topic aswell.

SO, as written in FAQ, is for Q/A not for discussions. Unfortunately or not, but that's the way it is... — Armen Tsirunyan, Nov 24 '10 at 11:20
Community Wiki!? Also might want to discuss .NET 5 async keyword. — mnemosyn, Nov 24 '10 at 11:29
This is neither a FAQ nor a Wiki thing (yet). So far I've just added my personal experience. I was looking forward for some more input bevore placing such a sensetive topic into a wiki. — Jaster, Nov 24 '10 at 11:33
It is no different from the question : hidden features of c# http://stackoverflow.com/questions/9033/hidden-features-of-c interview questions wpf http://stackoverflow.com/questions/58739/interview-questions-wpf-developer c# language features http://stackoverflow.com/questions/797014/does-c-have-too-many-language-features I feel people will benefit from a clarity between threading choices. — basarat, Nov 30 '10 at 05:21
Have a look [here](http://www.albahari.com/threading/). Good luck! — Homam, Nov 24 '10 at 11:46

score 2 · Accepted Answer · edited May 23 '17 at 11:58

Here are my two cents:

Thread: When you feel comfortable enough that you can handle all the IDEAL number of threads. This is almost always never the case. It is hear for people that would cry out that I want REAL threads not the .NET thread pool. If you don't want to ask this question : Optimal number of threads per core don't go with thread.

ThreadPool: This was the .net answer to in the box solution for the optimal number of threads. The API however was not the best. For new projects use TPL.

BackgroundWorker: If you are want to start threading from your GUI app with easy post backs. This provides the simplest API.

Dispatcher : Like you said. Just for calling back to the GUI thread. It is Vital for that. There is no other way you could use it anyways without some obscure code I do not know.
Note: It is not called delegate. Delegate is what you pass into a Dispatcher to dispatch.

Task Parallel Library : This came with .net 4. Recommended that you use it for new projects.

Parallel: No you got this wrong. Parallel.For will not return control until the entire loop is complete. It is there as a convenience when all you want to do is execute a loop in parallel. Great for mapping an input to an output e.g x -> x*2. Using Parallel.For (or ForEach) you can run this on multiple threads (again the number is decided by .NET) to run the loop faster. Check out: http://www.lovethedot.net/2009/02/parallelfor-deeper-dive-parallel.html

Discussion: Threading in .NET

1 Answers1