Boost logo

Boost :

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk