From: Christopher Currie (codemonkey_at_[hidden])
Date: 2004-06-30 12:50:47
Batov, Vladimir wrote:
> Getting back to Boost.Threads I'd still like to see a compelling example
> where I'd need to declare try_lock but twist its intuitive functionality
> into behaving like scoped_lock (that is blocking until locked).
In the need of extreme memory efficiency and speed: I already have, from
prior use, a scoped_try_lock 'l' around my mutex, currently unlocked. I
need to lock my mutex in a blocking fashion. I do not wish to pay the
memory and time cost to create an instance of scoped_lock just to do
this. I therefore call 'l.lock()' and not 'l.try_lock()'.
I don't know that it's compelling, but it is an example. I understand
your arguments for keeping the interface clean, but there are legitimate
reasons for wanting a blocking lock operation on a TryLock.
Constructor parameters are, admittedly, a different discussion, and most
of them boil down to syntactic sugar for a non-locking constructor and a
call to some locking operation, blocking or otherwise. But (IMO) it's a
useful syntactic sugar that *can* if used properly make programs less
cumbersome to construct without sacrificing correctness or clarity.
-- 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