Peter Dimov-5 wrote:
Johan Torp:
... The idea is to execute another task in the future::wait() call to avoid thread context switching and to need less worker threads. I've presented some arguments why this might cause unexpected problems.
It doesn't cause unexpected deadlocks if the thread is reused to execute the specific task that is supposed to produce the result of this particular future.
If I understand you correctly, it can deadlock. It can violate lock acquisition orders which may lead to dead locks. Assume we have two mutexes, M1 and M2 which is always supposed to acquired in order M1, M2. Thread A, task 1, pool task: submit task 2 acquire M2 wait on task 2 // Surprising that this call would acquire locks Thread A, task 2, executed from within wait on task 2 statement: acquire M1 // Acquired in wrong order Thread X: // Acquires mutexes in correct order acquire M1 acquire M2 I agree this might not be a very common case and that the added complexity might not be worth it. Holding a lock while waiting on a future seems stupid, but I believe having a lock acquisition order to avoid deadlocks is rather common. Johan -- View this message in context: http://www.nabble.com/-thread-pool-futures--Explicit-yielding-tp17606225p176... Sent from the Boost - Dev mailing list archive at Nabble.com.