Subject: Re: [boost] [task]
Date: 2009-10-02 14:50:04
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk