Boost logo

Boost :

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;


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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at