Click here to Skip to main content
15,446,510 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more: , +
Hi Experts,
I am using .NET Framework 5.0 and using Task Parallel Library (TPL).I have some confusion in Managed Thread Pool which TPL Use.

1)How many thread pool in machine having 4-Core Processor.?Is thread pool count depended on Operating System or Processor or Application ?
2)When we run the application either console,window or web etc . then they create their own thread pool or use existing one?

3)Where global queue reside in Thread Pool or some where else?where local queue reside?
how many global queue and how many local queue which factory dependent count of that.?
4)When Task goes into local queue.? Is every work which worker thread take from global queue first add in local queue the assign to the worker thread in thread pool or it run directly by worker thread.?
5)Why work stealing is done from global queue in FIFO and Local Queue in LIFO order what are benefits.?

First two question are very confused me.Please help?.

What I have tried:

The picture that is in my mind after reading couple of article is like that.
for 4 Core Machine. here GQ=>Global Queue

Core-1 Core-2 Core-3 Core-4
--- --------------- --- ---------- ----------- -----------
|G| -------------------
--- | Thread Pool |=======>Similarly Structure.
|Worker Thread-1..n|
|Worker Thread have|
|local Queue |
Each core have own thread pool and thread pool have worker thread and worker thread have local queue which pick up task from global queue.
<b>That's my imagination.</b>
Updated 10-Dec-16 14:53pm

1 solution

1) A thread pool is just a convenient thread manager. It increases and decreases the number of threads it uses based on load and can re-use threads to negate some overhead. It also keeps idle threads alive to further improve performance for repeated quick-running tasks. The maximum number of threads is set on the ThreadPool object. The absolute limit is based on the hardware you're running on - mostly on the stack space available. For most 32-bit systems you could probably squeeze out around 2,000.

2) Each process has a default thread pool. You can make more if you need pools with different attributes. No situation immediately comes to mind when this would be useful though. In fact ThreadPool is static in C# because unless you know how to write your own custom thread pool you probably shouldn't be using more. If you need more idle threads you can set that on the ThreadPool object.

3-4) The global queue is for the process. The local queue is for worker threads. For example, the process queues up Task1 in its global queue which is then executed by WorkerThread1. This task then spawns Task2. This Task2 is put into WorkerThread1's local queue. When WorkerThread1 is finished it pulls the most recent (LIFO) task out of its local queue. This is because that task has the highest chance to still be cached by the worker thread. When the local queue is empty the worker thread checks the global queue.

5) The process described above isn't work-stealing. That's just normal operation. Work-stealing is when a worker thread, after checking the global queue, checks other worker threads' local queues. It pulls tasks from the end of the list first (FIFO-style) because that reduces contention with the worker thread that actually owns that local queue since the local thread is pulling from the front of the list (LIFO-style). If cache optimization actually comes into play this would also ensure that the work-stealing is taking tasks that are more likely to not be cached by the local thread that owns the queue.

Other notes: One of the big advantages of the TPL is that you don't need to know all this stuff. That being said, I can understand curiosity - that's the only reason I know this stuff, haha =)

EDIT: I forgot to answer one of your questions! The ThreadPool class is what controls the global queue, local queues, and enables work-stealing.

Your picture would more accurately be:
| Process | -> Queues -> |  ThreadPool  |
-----------              ----------------
                         | Global Queue | <- ThreadPool has one
                         |    Worker    | <- ThreadPool can have multiple
                         || Local Queue|| <- Each Worker has one
Share this answer
Er. Dinesh Sharma 10-Dec-16 21:24pm     CRLF
Thank's McKee...for giving me some direction for above missing gaps. So the thing that I understand. 1)Mean each application(Process) have own thread pool. if we run ten application(process) then there is 10 thread pool. Am I right? 2)Is there any role of cpu core of system in thread pool.?
Jon McKee 10-Dec-16 21:43pm     CRLF
1) Yep. A ThreadPool is just a class that manages background threads. 2) Sorta? I've never seen the internals but I imagine ThreadPool uses the Thread class instead of re-inventing the wheel. A thread is simply a lightweight process. It's a separate execution path from the default execution path (commonly called the main thread) automatically started by the main process. These execution paths have to be run by the CPU. Cores can run multiple threads - it depends on the technology. If I remember correctly an i5 with 4 cores can run 4 threads (2 per core with hyper-threading) concurrently. There's a lot of other things that come into play with this though like context-switching between threads when there's a delay like I/O which means you can effectively run more. EDIT: Misread part of #2, fixed answer accordingly.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900