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