Hi! A static threadpool is not inherently unreasonable, but only supporting a single instance of threadpool is. The optimal number of worker-threads in the thread pool depends on the problem and is not always equal to the number of available cores. An example of a case where I get better performance running more threads than available cores is where I have synchronous I/O on each of the threads that means that on average 2 out of 4 threads are in the blocked state. It is measurably better to add two more threads into the thread pool and allow the CPU to be optimally utilised. There are clearly design alternatives using asynchronous I/O etc. but this is merely intended as an example. Since the optimal number of threads depends on the tasks performed on the threads it follows that only having one thread-pool with one configuration per process is a bad idea. I hope this helps, Neil Groves On Fri, Nov 21, 2008 at 1:55 PM, Oliver Kowalke <k-oli@gmx.de> wrote:
Hello, I did a look into draft n2276 - a launch_in_pool function is suggested (passing task to a system provided threadpool). Is it reasonable to have a static threadpool? How many worker-threads should this pool contain and how are the submitted tasks queued (FIFO, priority order ... unlimited/limited number of tasks can bes stored). What about applications which require a pool with different configuration than the static pool provides? Is it acceptable to pay for an unused pool?
regards, Oliver -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost