Re: [boost] [threadpool] draft n2276 - launch_in_pool

Subject: Re: [boost] [threadpool] draft n2276 - launch_in_pool
From: Anthony Williams (anthony.ajw_at_[hidden])
Date: 2008-11-21 10:10:07

"Oliver Kowalke" <k-oli_at_[hidden]> writes:

> 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?

Yes.

> 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).

In the proposal, that's up to the implementer to choose. The only
requirement is that in the absence of coding errors, a submitted task
will actually complete (i.e. the code should run as if each task was
on its own thread, but possibly delayed in starting). This contrains
the work-stealing algorithms in use, but allows the number of threads
to be dynamic, and the order to be up to the implementation. If the
pool cannot accept any more tasks (whether that's because there's a
hard-coded limit, or because it runs out of memory) then the task
submission should fail.

> What about applications which require a pool with different
> configuration than the static pool provides?

Don't use the static pool. Alternatively provide overloads of
launch_in_pool that allow task properties to be specified (e.g. "this
thread spends lots of time doing blocking waits" => maybe schedule an
extra thread).

> Is it acceptable to pay for an unused pool?

It could be initialized on first use.

Anthony
-- 
Anthony Williams
Author of C++ Concurrency in Action | http://www.manning.com/williams
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Just Software Solutions Ltd, Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK