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-18 16:03:43

viboes wrote:
> 
>> I mean that you want to intercept when a worker thread should have been
>> blocked and process other tasks in the wait call:
>>
>> void some_user_level_task() {
>> ...
>>  some_future.wait(); // Do not really wait, execute other tasks using the
>> same call stack
>> ...
>> }
> 
> Should this behaviour be extended to other synchronization functions like 
> mutex lock, condition wait, ... ?
> 

It is a very interesting idea, here are my thoughts;

First of all, I think even doing work in future::wait is a little to
automagic and think we should investigate if we can't make it explicit
somehow.

You probably do not want to do work while waiting for mutexes. They are only
supposed to help synchronize and order operations, waiting is just a side
effect of that. 

The idea of doing work while waiting on condition variables seems like a
natural extension of doing the same for futures since futures also have the
semantics of waiting for an event. Also, futures will most probably be built
on top of condition variables.

Perhaps some kind of policy with a default waiting behaviour; 

condition normal_condition_variable;
condition<WorkWhileWaiting> cv;
future<int> normal_future;
future<int, WorkWhileWaiting> f;

viboes wrote:
> 
> In addition the threadpool should provide a one step scheduling on the 
> *current* worker thread.
> 

There are certain subtle dangers with executing thread pool tasks belonging
to other threads, but they might be acceptable if this behaviour is explicit
(perhaps even if they aren't). IIRC, I discussed the matter with Peter Dimov
here in boost.dev but can't seem to find the thread.

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