Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at