----- Original Message ----- From: "Johan Torp" <johan.torp@gmail.com> To: <boost@lists.boost.org> Sent: Sunday, September 14, 2008 12:41 PM Subject: Re: [boost] [threadpool] relation with TR2 proposal
JOAQUIN M. LOPEZ MUÑOZ wrote:
http://www2.open-std.org/JTC1/sc22/wg21/docs/papers/2007/n2276.html
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" http://gee.cs.oswego.edu/dl/papers/fj.pdf java doc http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/FJTask.html java source http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/FJTaskR... 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: www.johantorp.com
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: http://www.threadingbuildingblocks.org/documentation.php
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 FJTaskRunner.java 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? Regards, Vicente