TaskFactory miss running tasks

Question

Is it possible for the TaskFactory to not run a task for a long time if there are too many tasks queued up already? If so, there a way to configure the taskfactory so that it is able to run more tasks quicker.

Also, will there be any issues with using both the TaskFactory and the Threadpool.QueueUserWorkItem within the same process? We have some older libraries that still use the Threadpool class.

Answer 1

Using TPL, your task will enter the thread pool automatically; where the thread pool keeps tabs on the number of running threads it will run simultaniously. Too many active threads will kill performance with adminastrative burden on the OS. Once the predefined limit on the number of threads is reached they are then queued. Some background...

The thread pool starts out with one thread in it pool and the pool manager ‘injects' new threads to cope with extra asynchronous workload, upto some limiting maximum. After a set period of inactivity the pool manager may 'retire' threads if it 'thinks' that doing so will lead to a better throughput. In your case above the pool manager is limiting the number of concurrent threads.

You can set the upper limit on the number of threads the pool will create by calling Thread.Pool.SetMaxThread;, the defaults are:

1023 in Framework 4.0 in a 32-bit environment.
32768 in Framework 4.0 in a 64-bit environment.
250 per core in Framework 3.5.
25 per core in Framework 2.0.

[these figure may vary according to hardware and OS].

The reason for these vast number (at least in the case of .NET 4.0) is to ensure that progress is made even when some threads are blocked (running some intense work etc.)

You can set the lower limit via ThreadPool.SetMinThreads. The role of this limiter is more subtle than that of the max limiter: this instructs the pool manager not to delay the creation of threads until reaching this lower limit on number - setting this number will improve you concurrency when there are blocked threads.

You cannot use TPL if you are using an earlier version than Framework 4.0. You could use 4.0 and call QueueUserWorkItem - this (at first glance) should not cause you any problems.

I hope this helps.

Answer 2

Alvin. When you queue up tasks to run, they will be scheduled to run using threads from the ThreadPool. How many tasks are run, and how quickly they run will be based upon the number of available threads and how long a particular task takes to execute. The threadpool is capable of spinning up new threads as required if there are a lot of queue tasks, but this will largely depend upon available resources and cpu's. The threadpool can be configured to set the default number of threads, but this is not recommended in most circumstances.

There should not be any issue using both Tasks and the Threapool.QueueUserWorkItem together as the default Task scheduler uses the same threadpool. All that will happen is that you will have more queued tasks awaiting processing by same threadpool.