On Jul 7, 2004, at 9:19 AM, Michael Glassford wrote:
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.
Agreed, and I think the scoped_try_lock got it wrong (i.e. scoped_try_lock(mut) should block). This somewhat irritates me as I have coded and shipped Metrowerks::scoped_try_lock with the wrong semantics (doesn't block). :-\ I'm finding more and more uses for generic lock code. The generic helper I showed yesterday was one. Another is: template <class TryLock1, class TryLock2> class lock_both { public: lock_both(TryLock1& m1, TryLock2& m2, bool lock_it = true); ~lock_both(); void lock(); bool try_lock(); void unlock(); bool locked() const; operator int bool_type::* () const; private: lock_both(const lock_both&); lock_both& operator=(const lock_both&); }; which allows you to lock two locks without fear of deadlock. So consistent syntax/semantics across lock types is a real win. -Howard