Re: [boost] [thread] RFC standard proposed mutex, read-write mutex, condition

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2007-08-22 13:30:42

Yuval Ronen wrote:
> Howard Hinnant wrote:
>> On Aug 21, 2007, at 7:34 PM, Yuval Ronen wrote:
>>
>>> All this complexity is simply unnecessary, IMO. You can drop the
>>> lock/try_lock/unlock functions from the locks, keep them for mutexes,
>>> and declare that std::lock/scoped_lock/unique_lock work only for
>>> mutexes. You can then drop defer_lock also, and everything is much
>>> simpler...
>> Consider a use case where the mutex, but not the lock has been  
>> encapsulated away, and you want to unlock the lock prior to its  
>> destruction:
>>
>> typedef std::mutex Mutex;
>>
>> Mutex&
>> get_mutex()
>> {
>>      static Mutex mut;
>>      return mut;
>> }
>>
>> typedef std::unique_lock<Mutex> Lock;
>>
>> Lock
>> get_lock()
>> {
>>      return Lock(get_mutex());
>> }
>>
>> typedef std::condition<Mutex> Condition;
>>
>> Condition&
>> get_condition()
>> {
>>      static Condition cv(get_mutex());
>>      return cv;
>> }
>>
>> void foo()
>> {
>>      Lock lk = get_lock();
>>      change_data();
>>      if (some_flag)
>>      {
>>          lk.unlock();                  // <--------- here
>>          get_condition().notify_all();
>>      }
>> }
> 
> Instead of lk.unlock(), we can write lk.get_mutex().unlock(), for example.
> 
> Another option is to say that encapsulating away the mutex is not a 
> valid use case. Remove the get_lock() function and write:
> 
> void foo()
> {
>      Mutex &m = get_mutex();
>      Lock lk(m);
>      change_data();
>      if (some_flag)
>      {
>          m.unlock();
>          get_condition().notify_all();
>      }
> }

Of course I forgot lk.release() at the right places...