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

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2007-08-22 12:37:44

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

I don't see any benefit in encapsulating the mutex. Just like 
unique_ptr<T> doesn't encapsulate the T.

> Question 10 shows a motivating use case for defer_lock that does not  
> involve the member lock/unlock functions on locks.

It does involve them, even though not directly. If we remove 
lock/unlock, then there is no reason for unique_lock to have a 'bool 
owns' data member. The ownership is detemined by null-ness of the 
'mutex_type* m' data member. And now the second return statement in Q.10 
(the 'else' part) can be replace with 'return 
std::unique_lock<std::mutex>()'. No need for defer_lock.