Re: [boost] [thread-pool/futures] Explicit yielding (fork/join)

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.

Johan
-- 
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.