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