Am Freitag 02 Oktober 2009 19:33:32 schrieb vicente.botet:
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?
worker in boost.task use mutex/condition in queues and get notifed if new work was enqueued (queue::take() etc.)
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?
boost.task-0.4.0 uses fibers and a user-mode-scheduler inside the threadpool
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.
htere is no need that the user does the scheduling - this_task::block() stops the execution of the current task and passes it to the internal user-mode- scheduler which reschedules the task (if the condition is not ready the task gets blocked again)
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?
not yet - I do some finish (docu etc.) - only the svn-repo contains a snapshot best regards, Oliver