Thread programming III Tuesday, November 13 2007
Threads consume resources, applications that spawn new threads do not scale well especially on server side applications. Rather than creating threads manually, runtime system/OS supports thread pool. What happens when we create new thread? Thread object is created and initialized, thread stack is created and initialized, sending notification to all the dll’s that are part of the process, and similar work has to be done when thread needs to be disposed.
Thread pool is the answer to avoid such resource consumptions. So the run time optimizes the size of the thread pool according to available resource. For ex: .net runtime Initiates thread pool with zero threads, when applications wants to create a new thread that should request to the thread pool, the request is queued on Thread pool Queue. Then the first thread created, when the first thread completes given task that is not destroyed immediately instead it is returned to the thread pool in a suspended state. Hence It will wake up and become available immediately (without creating thread object, stack, notification and initialization) for the further request. New threads added on demand to the pool when app requests are not able to handle by current thread pool threads.
It is desirable to have many threads (tasks) than cores that allow much better load balancing among the cores. If one thread has been assigned more work then others, the application may not use cores effectively, In general applications can use algorithm to assign largest task to a thread which has least amount of assigned work. This is a recursive task, in most cases, we may need to do code inspection and re-designing more balanced thread model, or modifying balancing algorithm or even sometimes re-architecting whole application.
I am not able to imagine how this parallelism is useful for desktops/notebooks, especially when they have 8 cores and each runs 3GHz, any application can use all the processing power?I don't know.
