Re: [boost] [task]

Subject: Re: [boost] [task]
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-10-02 13:33:32

Hi Oliver,

----- Original Message ----- 
From: <k-oli_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, October 02, 2009 6:59 PM
Subject: Re: [boost] [task]

> 
> First - boost.task is the  successor of boost.threadpool and uses the wait-
> notifications too (but doesn't wait infinit because some co-worker-thread could 
> have produced additonal tasks which could be stolen).

Could you explain why a single mutex/condition at the pool level is not workable to wait/signal for all the task submitions?

If this is possible it would be great to implement it either by conditional compilation or as policy of the pool, and compare the result on different contexts. Anyway I don't this is necessary to in a first time, as it concerns an implementation performance and should not have any interface break.
 
> Second - I'm finishing boost.task-0.4.0 which replaces 
> this_task::reschedule_until() by this_task::block().
> block() suspends the current task without blocking the worker-thread. The 
> blocked task gets rescheduled by the internal scheduler (returning from 
> block()):
> 
> while ( ! condition)
> this_task::block();

Oliver, does it means that you will integrate your Boost.Fiber library on version 0.4?

In order to avoid polling on the condition, it would be great if the user can  get a handle of the blocked task and reschedule it when the condition could be true.

> Version 0.4.0 allows to synchronize or exchange messages between the tasks 
> without deadlocking the threadpool (that means amount of tasks >> worker-
> threads in pool).

Is there already something new on the sandbox we could inspect?

Best regards,
Vicente