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

From: Christopher Currie (codemonkey_at_[hidden])
Date: 2004-06-29 08:00:30

Batov, Vladimir wrote:

> Guys,
> 
> Could we please resist complicating interfaces when we do not have to? I
> personally consider an additional blocking parameter for something like
> try_lock excessive because it distorts try_lock into becoming
> scoped_lock.

try_lock *is* scoped_lock, it just also supports a non-blocking locking 
operation.

> Let's keep different concepts different. Blocking in
> try_lock is an oxymoron -- try_lock cannot block because it is "try".

What if I want it to? Just because it supports a non-blocking lock 
operation, doesn't mean it can't support a blocking one, and in some 
situations I may want to block on the mutex without having to create 
another lock object.

> The basic usages (covering about 80%) are:
> 
> scoped_lock l(m); // Block until it locks.
> scoped_try_lock l(m); // Try (!) to lock. I'll check the result.

I disagree here, as well. Say I want to program generically...

template <typename Mutex, typename Lock>
class worker_class
{
   Mutex m_;

public:
   do_work()
   {
      Lock l(m_); // Does this call block?
      // am I guarenteed to be locked here?
   }
}

Yes, it's a contrived case, but the point is that all locks should have 
the same behavior in the 1-argument constructor case, and that is to 
block until this lock is obtained. The is the only way the user can use 
the lock in a generic way.

-- 
Christopher Currie <codemonkey_at_[hidden]>