[boost] Re: Boost.Threads: Do we need all those mutexes?

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-07-07 08:19:31

Peter Dimov wrote:
> Howard Hinnant wrote:
> 
>>I like the latent_write_lock / upgradeable lock idea proposed by Bruno
>>/ Alexander.  I have been playing with the following interface:
>>
>>namespace detail
>>{
>>
>>template <class RW_Mutex>
>>class read_lock
>>{
>>public:
>>     typedef RW_Mutex mutex_type;
>>
>>     explicit read_lock(mutex_type& m, bool lock_it = true);
>>     explicit read_lock(upgradable_read_lock<mutex_type>& r);
>>     explicit read_lock(write_lock<mutex_type>& w);
>>
>>     ~read_lock();
>>
>>     void lock();
>>     bool try_lock();
>>     void unlock();
>>     bool locked() const;
>>     operator int bool_type::* () const;
>>
>>private:
>>     read_lock(const read_lock&);
>>     read_lock& operator=(const read_lock&);
>>};
> 
> 
> [...]
> 
> Seems very good to me. Also demonstrates a better lock taxonomy 

Better compared to what? The current read/write lock taxonomy? One of 
the many suggestions in this discussion?

 > (which
> allows me to include some on-topic content ;-) ):
> 
> Lock
> 
>     Lock( Mutex&, bool = true );
>     void lock();
>     void unlock();
>     bool locked() const;
>     operator int bool_type::* () const;
> 
> TryLock: Lock
> 
>     +bool try_lock();
> 
> TimedLock: TryLock
> 
>     +bool timed_lock( xtime const & );

The point being that TryLock is a refinement of Lock, and TimedLock is a 
refinement of TryLock? If so, I agree that's better than TryLock and 
TimedLock both refining Lock. There are still the constructor issues to 
deal with in such a lock taxonomy, however. The main one: how do you 
define destructors that are consistent within a lock concept and also 
consistent between concepts. E.g., on the one hand it seems that a 
one-parameter constructor should do the same thing in all lock types--so 
it would have to block; on the other hand, it seems that TryLock 
constructors should not block unless instructed to do otherwise.

Mike