Boost logo

Boost :

Subject: Re: [boost] [threadpool] relation with TR2 proposal
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-09-16 01:20:33

----- Original Message -----
From: "Johan Torp" <johan.torp_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Sunday, September 14, 2008 12:41 PM
Subject: Re: [boost] [threadpool] relation with TR2 proposal

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

It's my _guess_ also. I think that the Boost threadpool library must
integrate child-tasks and task stealing between worker threads.

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

Are you talking about the C++ standard efforts? The n2276 proposal is a
simple thread pool without possibility to steel tasks betweer worker
threads. Are there other work in progress?

Some references on fork-join framework for the reader:
article "A Java Fork/Join Framework"

java doc

java source

BTW, is someone already working on the FJTask adaptation to C++, or
something like that?

> 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
> languages.
> Read section 4.6 of my master's thesis to get a basic understanding of
> thread-level scheduling, it can be found at:

I'll take a look. Could you resume the conclusion of your thesis?

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

Doesn't FJTask expose the worker thread on class?

What do you mean by a decent implementation?

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

Could you elaborate more, which difficulties?
What is missing on the current Future proposals for you?



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