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@gmail.com>