From: Howard Hinnant (hinnant_at_[hidden])
Date: 2004-07-07 10:26:51
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>
lock_both(TryLock1& m1, TryLock2& m2, bool lock_it = true);
bool locked() const;
operator int bool_type::* () const;
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk