Re: [Boost-users] interprocess_condition::wait(scoped_lock<interprocess_upgradable_lock> &) missing

Subject: Re: [Boost-users] interprocess_condition::wait(scoped_lock<interprocess_upgradable_lock> &) missing
From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2011-02-04 19:41:39

On Feb 4, 2011, at 12:54 PM, Ion Gaztañaga wrote:

> El 04/02/2011 3:05, Howard Hinnant escribió:
> 
>> In this set condition_variable_any and unique_lock are in C++0x.  I
>> hope to propose shared_lock and shared_mutex for tr2 and ultimately
>> c++1x.  Field experience here (good or bad) would help.  Here is a
>> tutorial and implementation of the shared and upgrade mutexes and
>> locks:
>> 
>> http://home.roadrunner.com/~hinnant/mutexes/locking.html
>> 
>> Here is an implementation of condition_variable_any:
>> 
>> http://llvm.org/svn/llvm-project/libcxx/trunk/include/condition_variable
> 
> Thanks Howard! Just two comments:
> 
> a) Windows Vista condition variables natively supports Slim Reader/Writer Locks (http://msdn.microsoft.com/en-us/library/ms686304%28v=VS.85%29.aspx), the implementation could take advantage of this if shared_mutex is based on this primitive.

<nod> Agreed.

> 
> b) Is there any reason to store shared_ptr<mutex> instead of a mutex?

Yes.  I missed this subtlety for years.  I think it was Peter Dimov who pointed it out to me:

Thread A notfies the condition_variable_any, which thread B is waiting on.  Then thread A destructs the condition_variable_any before thread B wakes and returns from the wait.  This is supposed to work.  The POSIX condition variable also works this way.  The shared_ptr is used to share ownership of the mutex between the condition_variable_any, and the thread running the wait function.  If the condition_variable_any destructs while the wait is running, the mutex stays alive long for the wait function to lock and unlock it, and then destructs when the wait returns.

-Howard