Boost logo

Boost :

From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-06-13 07:59:18

Kowalke Oliver (QD IT PA AS) wrote:
>> Tasks can internally re-submit child tasks and then wait on
>> the child task.
>> This is probably a quite common usecase, see the paper.
>> Also, somebody else might start working on your child task.
>> Instead of waiting for them to complete you could start
>> working on other worker threads' problems or top-level tasks.
>> This can cause some problems though, such as unexpected deadlocks.
> I did a look in the papers for for/join and work stealing algorithms.
> Is it correct that each fork of a subtask would create a new thread (which
> get joined later)?

No, I don't think that would be the typical implementation. Rather you would
have a thread pool of worker threads, somewhat correlated to the number of
cores on the machines. The idea is that if one of the worker threads blocks
on a task, it could do other work in it's wait() call. This is to prevent
thread startup and thread context switching. If the language had support for
coroutines/yielding or fibers there might be better ways of acheiving
efficienct work <-> cores mapping.


View this message in context:
Sent from the Boost - Dev mailing list archive at

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