Re: [boost] [threadpool] relation with TR2 proposal

Subject: Re: [boost] [threadpool] relation with TR2 proposal
From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-09-27 09:35:49

Anthony Williams-4 wrote:
> 
>>>> 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?
>>
>> There are at least two things which still needs be solved:
>> 1. How to wait for multiple futures
> 
> My futures prototype at
> <http://www.justsoftwaresolutions.co.uk/threading/updated-implementation-of-c++-futures-3.html>
> handles that.
> 

I'm not very satisified with that interface, but I may very well be missing
something. For instance, can you implement additions of futures on top of
your interface? future<int> operator+(future<int>, future<int>). 

Rather than having to gather up all futures from all over a program and
having to wait for them in one single place, I think it would provide a lot
of value if you could compose futures to an arbitrary depth. That is, I do
not want a construct that is similar to POSIX select or Windows'
WaitForMultipleObject as they really mess with program structure.

Also, your dynamic wait_for_any implementation requires O(N^2) operations in
cases where you want to wait until one value is ready, do something, then
resume waiting until the next one ready and so on. 

Anthony Williams-4 wrote:
> 
>> 2. How to employ work-stealing when one thread waits on a future
>>
>> An expressive solution is to allow some callback hooks (for future::wait
>> and
>> promise::set) but that is quite hackish. IMO you should not be able to
>> inject arbitrary code which is run in promise::set via a future object
>> that
>> runs on a completely different thread. 
> 
> Yes. This needs to be internal to the implementation, which requires
> the future and thread pool to cooperate.
> 

It doesn't necessarily need to be internal. It could be code aimed to be
executed in a thread pool should explicitly wrap their waiting:

// Will employ work stealing if this_thread is a worker thread
void wait_or_work_steal(future<...>)

I'm far from convinced that an automagical solution where futures cooperate
with a single instance thread pool is the best. That means a lot of coupling
and I'm not sure it will provide much value. 

I think a future value is such an important construct in its own right, that
thread pool design decisions should not be allowed to affect it very much.
Thread pools need a really lightweight task abstraction to allow extraction
of finer grain task level parallelism, i.e. futures should try to be
lightweight (if std::unique_future really should be the return value from a
thread pool). Other than this, I'm not sure how much a thread pool should be
allowed to affect the future design and implementation. IMHO, an imagined
thread pool implementation should be one of many "test users" of a future
implementation to see if the API and implementation is satisfactory.

Johan
-- 
View this message in context: http://www.nabble.com/-threadpool--relation-with-TR2-proposal-tp19452045p19702802.html
Sent from the Boost - Dev mailing list archive at Nabble.com.