Re: [boost] [threadpool] new version - with reschedulingofcurrenttask

Subject: Re: [boost] [threadpool] new version - with reschedulingofcurrenttask
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-02-28 07:59:02

----- Original Message ----- 
From: <k-oli_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Saturday, February 28, 2009 12:36 PM
Subject: Re: [boost] [threadpool] new version - with reschedulingofcurrenttask

> 
> Am Saturday 28 February 2009 10:43:10 schrieb vicente.botet:
>> If I understand then we will have two function win the same name in
>> different namespaces. Does ADL found the good one,i.e. if the user see
>> boths overloadings, will wait_for_all(f1, f2) call the the future
>> overloading and wait_for_all(t1, t2) calls the task overloading or do we
>> need to prefix with the namespace?
> 
> I suggest to prefix it - but I could also rename the threadpool specific ones

My concerns is how a generic algorithm can use wait_for_all on either futures or tasks or a mixture of them.The problem with boths wait_for_all implementations is that you can only wait for futures or wait for tasks. You can not wait for some futures and some task. If the task class provided a way to get the future it uses in its implementation, we can implement a wait_for_all that works with a mixture of tasks and futures, and why not the joiners of Boost.Interthreads? interthreads::wait_for_all allows that as soon as the ACT provided a way to get a future from it, and forwarding to the Boost.Futures wait_for_all. So the following is possible.

    unique_future<int> f;
    tp::task<string> t;
    interthreads::joiner<double> j;

    interthreads::wait_for_all(f,t,j);

Hence my request to have a way to get a future from a task.

>> Well the question is, what happens if the condition don't retuns true? The
>> task doing this will be blocked, but only this task. The worker thread will
>> continue to schedule other tasks, of course testing each time this
>> condition. It seems to me a good compromise.
> 
> This is already provided by the task wait functionality (wait(), get() etc.).
> If task::get() or task::wait() would block because the associated future is 
> not ready the worker thread automatically reschedules, e.g. executes other 
> items from the pool channel.

Yes I know that and it is very useful as far as the condition can be enabled by another task. But a task can not satisfy sleeping for a while without blocking the thread. Or waiting on a condition modifyed by another thread and having nothing to be with the ThreadPools library. I really think that the task on a ThreadPool frameworks need this kind of synchronization mechanism.

> I think a explicit reschedule_until() is not required and dangerous.

Why do you consider that it is dangerous? I'm missing something?
 
> tp::task< int > t1(
> boost::this_task::get_thread_pool< pool_type >().submit(
> boost::bind(
> & fibo::par_,
> boost::ref( * this),
> n - 1) ) );
> 
> t1.get(); // rescheduling if t1.get() would block == until t1.get() would nont 
> block other items from the pool channel are executed.

The problem with this approach is that the task can not wait on a condition without blocking the worker thread, 
This is  is exactly the role of reschedule_until(), poll a condition and do something else when the condition is not satisfied. Where is thedanger? Could you give an example?

Best,
Vicente