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

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-07-07 11:30:41

Howard Hinnant wrote:
> 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).

I've come to agree with you on this, and hope to fix it one way or 
another (see other replies in this discussion).

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

I'm glad to know this; I wondered at first whether generic uses of locks 
would be at all common or important.

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

Agreed. I always like as much consistency as possible, which is why I 
started the whole lock constructor discussion.

Mike