Differences in the different ways to make concurrent programs

Question

What is the difference between:

1. Starting a new thread
2. Using TPL
3. Using BackgroundWorker

All of these create concurrency but what are the low-level differences between these? Do all 3 make threads anyway?

Thanks

Answer 1

They all use threads internally, the differences are to do with the abstraction level of each API and how the threads are utilised. Lets re-order your list a bit and look at the three techniques from lowest to highest levels of abstraction:

1. Starting a new thread manually:

   This actually creates a new thread in the OS. Your code will be executed on that thread.

2. Using a BackgroundWorker:

   Internally this uses something called the .net ThreadPool. The thread pool is basically a pool of available threads. Your code is assigned onto one of the available threads and is run on that thread.

   The pool manages the number of available threads and will internally create and destroy threads as required within certain bounds. This is useful because the pool can have some algorithms to optimise thread creation. Thread creation is quite an expensive process, so if appropriate the thread pool keep threads alive and reuse them for future requests. You can have some limited control over the pool by specifying min/max numbers of threads and some minor tweaks like that.

   There are other ways of using the ThreadPool directly such as QueueUserWorkItem(...).

3. Using the Task Parallel Library:

   This is an even higher abstraction. You create "tasks" and tell the TPL to execute them. The TPL hides all the concerns regarding exactly how many threads and what priorities will be used etc. The TPL has the ability to reuse threads and manage them according to specific machine performance and available CPU resources.

   For example given 100 tasks, on a Quad core the TPL might spawn 4 threads, but on an 8 core it might spawn 8 and distribute the tasks over the available threads as each task completes.

So to answer you question. All 3 techniques use threads, but as you go up each level the amount of control and awareness you have over those threads is reduced.

In most cases, I would recommend you use the TPL. Unless you need specific very exact control over the number of threads and their creation/destruction the TPL will handle it all very well for you.

Answer 2

1. Starting a new Thread is the most expensive of the three, but you get the most possibilities. Like setting the Apartment model and priority.

2. Task Parallel library will run a task on the ThreadPool (unless a Task is marked as needing its own Thread) and adds Exception handling and Wait-for-completion functionality.

3. The BackgroundWorker is only useful to run Tasks spawned from WinForms or WPF. It also uses the Threadpool

4. Extra: the ThreadPool. Used to run short tasks w/o the overhead of creating a separate Thread.

Answer 3

Creating a thread is just that... you spawn a single thread to run concurrently to your main process thread.

In TPL if you create a Task it will use a thread pool to find a free thread to run the task. This can be more efficient when you create lots of tasks because TPL is able to balance the load across any number of free threads (presumably the # of threads is balanced based on the # of cores you have, but i dont know this for sure.)

Finally, a BackgroundWorker runs your work on a separate thread. It is really just a nice abstraction that removes you from the messy parts of threading since it is managed for you. It also provides a way to send back status updates if i'm not mistaken. (not sure if this uses the Windows thread pool, but i wouldn't be surprised)

In the end, you have to choose what is right for your program, but the purpose of TPL Tasks is to allow you to effectively schedule tasks that can be run in parallel whereas creating threads or using background workers might be better for long running operations or for scenarios where you want the background thread to live forever waiting for some signal (through i would actually suggest using a RegisteredWait if you're just waiting for some event to signal.)