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

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2007-08-22 15:54:16

David Abrahams wrote:
> on Mon Aug 20 2007, Howard Hinnant <howard.hinnant-AT-gmail.com> wrote:
> 
>> Here is a link to a reference implementation and a FAQ for mutexes,  
>> locks and condition variables I am currently anticipating proposing  
>> for C++ standardization (or subsequent TR).
>>
>> http://home.twcny.rr.com/hinnant/cpp_extensions/concurrency_rationale.html
> 
> I find the fact that unique_lock can reference a mutex without owning
> the mutex's lock rather confusing in light of the semantics of
> unique_ptr.  It seems like unique_lock is looking more like the
> old-old auto_ptr.
> 
> And what does it mean to construct a unique_lock from a shared_lock?
> How many owners are there if I copy a shared lock and construct a
> unique_lock from the copy?  Fundamentally I want to know what is
> really "unique" about unique_lock.

I really prefer the older "exclusive_lock" name. This way lock names 
indicate the type of locking mechanism that they will call on the passed 
mutex (lock()=exclusive, lock_shared()=shared, lock_upgrade()=upgrade) 
and we don't suggest that the lock "owns" the mutex as the "unique" name 
might suggest. Several unique_lock's can refer to the same underlying 
mutex, something that would never happen with unique_ptr.

Just my 2 cents,

Ion