Re: [boost] [thread-pool/futures] Explicit yielding

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