From: Batov, Vladimir (Vladimir.Batov_at_[hidden])
Date: 2004-07-01 16:24:42
According to the current Boost.Threads documentation timed_wait() does
not require timed_lock (cut and pasted from
template <typename ScopedLock>
bool timed_wait(ScopedLock& lock, const xtime& XT);
Looking at the code it does appear to require timed_lock either:
template <typename L>
bool timed_wait(L& lock, const xtime& xt)
return do_timed_wait(lock.m_mutex, xt);
What am I missing?
BTW. How can I get to have look at the development branch? I went to
http://cvs.sourceforge.net/viewcvs.py/boost/boost/development/ but found
[mailto:boost-bounces_at_[hidden]] On Behalf Of Michael Glassford
Sent: Friday, 2 July 2004 4:35 AM
Subject: [boost] Re: Boost.Threads: Do we need all those mutexes?
Batov, Vladimir wrote:
>>Well, as you point out, try_lock is like a timed_lock with
>>time = 0, and lock is like a timed_lock with time = infinity,
>>so why not give timed_lock both lock() and try_lock()
>>methods as shorthand notation for lock(m, t=0) and
> [Batov, Vladimir] Because, in my view, it violates the fundamental
> I think widely accepted) OO design principle (guideline?) that in
> terms can be expressed as "one class, one responsibility". Names like
> Bertrand Meyer, Herb Sutter and many others immediately come to mind.
> We can either achieve that by having a universal lock (with timed_lock
> as the basis) and shorthand notations in separate derived classes
> timed_lock and try_lock) or by keeping those three completely
> (probably at the expense of some code/functionality duplication). I am
> personally leaning towards latter, as even though technically all
> concepts are related, from the user point of view they are distinct.
>>The argument for try_lock not having a blocking lock() method,
>>which you seem to stress more often, is much clearer; I'm much
>>more inclined to agree with you there.
> [Batov, Vladimir] Thank you. I feel that it is important that every
> class does what it promises to do. No more, no less.
For what it's worth, heres a use case I just ran across illustrating why
timed_lock should have a blocking lock() method and/or a blocking locked
void f(mutex m)
mutex::scoped_timed_lock l(m, locked);
//always want the lock here
//timed_wait requires a timed_lock
Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk