Boost logo

Boost :

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2007-11-14 09:20:04

Alexander Terekhov <terekhov_at_[hidden]> writes:

> "Preston A. Elder" wrote:
> [...]
>> IF (!interruption_enabled)
>> cond.wait(lock);
>> 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 Williams
Just Software Solutions Ltd -
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

Boost list run by bdawes at, gregod at, cpdaniel at, john at