Boost logo

Boost :

Subject: Re: [boost] [threadpool] relation with TR2 proposal
From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-09-14 06:41:21

> What is the relationship with this proposal of the threadpool library
> that is being
> discussed these days here at the Boost list?

My _guess_ is that the C++ standard committee is targeting a thread pool
which can help to ease extraction of parallel performance, not a fully
configurable templated thread pool with lots of neat features.

I believe the standard efforts are inspired by what java (see
java.util.concurrency and the part called the fork-join framework) and .NET
standard libraries (TPL, task parallel library) and intel thread building
blocks (a C++ library) provide. They all have thread pools which internally
employs work stealing-based scheduling and tries to keep a number of worker
threads equivalent to the number of cores. Above the thread pool, there are
constructs such as parallel_for. Having such high-level constructs is going
to be very important in extracting parallel performance of thread based

Read section 4.6 of my master's thesis to get a basic understanding of
thread-level scheduling, it can be found at:
And see intel TBB excellent tutorial which explains their approach in rather
much detail:

My five cents is that it would be great to separate the concerns of a thread
pool and scheduling. But the real value for most applications would be to
have parallel constructs (such as parallel_for) built on a single thread
pool with smart work-stealing scheduling and a number of worker threads
hinted to be bound to cores by processor affinity. To my knowledge, out of
the .NET, java and TBB, only TBB exposes its thread pool. Hence, a simple
interface such as launch_in_pool with a decent implementation might provide
a lot more value than a fully configurable thread pool library.

In practice, just providing the interface to launch_in_pool has proven
difficult as it returns a future value. The problem is nailing down a future
interface which is both expressive and can be implemented in a lightweight

Best Regards, Johan Torp

View this message in context:
Sent from the Boost - Dev mailing list archive at

Boost list run by bdawes at, gregod at, cpdaniel at, john at