Re: [boost] [thread] thread interruption semantics

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);
>> 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