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-tp17606225p178... Sent from the Boost - Dev mailing list archive at Nabble.com.