From: Christopher Currie (codemonkey_at_[hidden])
Date: 2004-06-29 08:00:30
Batov, Vladimir wrote:
> 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
try_lock *is* scoped_lock, it just also supports a non-blocking locking
> 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>
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