|
Boost : |
Subject: Re: [boost] [threadpool] draft n2276 - launch_in_pool
From: Neil Groves (neil_at_[hidden])
Date: 2008-11-21 09:01:43
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_at_[hidden]> 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
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk