Alexander Terekhov <terekhov@web.de> writes:
"Preston A. Elder" wrote: [...]
IF (!interruption_enabled) cond.wait(lock); ELSE interruption_checker check(cond); lock.unlock(); lock.internal_lock.lock(); cond.wait(lock.internal_lock); lock.internal_lock.unlock(); if (check.interrupted) throw thread_interrupted; lock.lock(); // uses the above mutex::lock(), so interruptable.
This way the condition still has the same interruption semantics as you
This is broken condition variable. It doesn't ensure "atomic" release of a lock and blocking the calling thread ("atomic" with respect to locking that same lock by another thread and then signaling condition variable).
Yes. You have to lock the internal mutex before you unlock the external one. Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL