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.