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