[boost] Re: Boost.Threads: Do we need all those mutexes?

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>
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