From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-06-02 17:19:56
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
> specific task that is supposed to produce the result of this particular
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
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
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
-- View this message in context: http://www.nabble.com/-thread-pool-futures--Explicit-yielding-tp17606225p17611048.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