using .NET 4 Tasks instead of Thread.QueueUserWorkItem

Question

I've been reading bunch of articles regarding new TPL in .NET 4. Most of them recommend using Tasks as a replacement for Thread.QueueUserWorkItem. But from what I understand, tasks are not threads. So what happens in the following scenario where I want to use Producer/Consumer queue using new BlockingCollection class in .NET 4:

1. Queue is initialized with a parameter (say 100) to indicate number of worker tasks. Task.Factory.StartNew() is called to create a bunch of tasks.

2. Then new work item is added to the queue, the consumer takes this task and executes it.

Now based on the above, there is seems to be a limit of how many tasks you can execute at the same time, while using Thread.QueueUserWorkItem, CLR will use thread pool with default pool size.

Basically what I'm trying to do is figure out is using Tasks with BlockingCollection is appropriate in a scenario where I want to create a Windows service that polls a database for jobs that are ready to be run. If job is ready to be executed, the timer in Windows service (my only producer) will add a new work item to the queue where the work will then be picked up and executed by a worker task.

Does it make sense to use Producer/Consumer queue in this case? And what about number of worker tasks?

Answer 1

I am not sure about whether using the Producer/Consumer queue is the best pattern to use but with respect to the threads issue. As I believe it. The .NET4 Tasks still run as thread however you do not have to worry about the scheduling of these threads as the .NET4 provides a nice interface to it.
The main advantages of using tasks are:

• That you can queue as many of these up as you want with out having the overhead of 1M of memory for each queued workitem that you pass to Thread.QueueUserWorkItem.
• It will also manages which threads and processors your tasks will run on to improve data flow and caching.
• You can build in a hierarchy of dependancies for your tasks.
• It will automatically use as many of the cores avaliable on your machine as possible.