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: http://www.nabble.com/-thread-pool-futures--Explicit-yielding-tp17606225p17821848.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk