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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-07-07 08:49:13

Michael Glassford wrote:
> Peter Dimov wrote:
>> Howard Hinnant wrote:
>>
>> [ read/write mutexes and locks ]
>>
>> 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?

Better compared to the current non-read-write lock taxonomy.

>> 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.

I don't see any. There is one constructor, with the same behavior.

> The main one: how do you
> define destructors that are consistent within a lock concept and also
> consistent between concepts.

~Lock { if( locked() ) unlock(); }

however it looks like you meant 'constructor'.

> 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.

I meant what I said. There is a single constructor. Its behavior is
consistent across all lock concepts (it it weren't, a TryLock would not be a
Lock). A mutex exposes a single lock type, which is as refined as possible.