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 lock(m, t=infinity)?
[Batov, Vladimir] Because, in my view, it violates the fundamental (and I think widely accepted) OO design principle (guideline?) that in simple 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 (lock, timed_lock and try_lock) or by keeping those three completely unrelated (probably at the expense of some code/functionality duplication). I am personally leaning towards latter, as even though technically all
According to the current Boost.Threads documentation timed_wait() does not require timed_lock (cut and pasted from http://www.boost.org/libs/thread/doc/condition.html#class-condition): 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) { if (!lock) throw lock_error(); 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 nothing threads-related. Thanks, V. -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Michael Glassford Sent: Friday, 2 July 2004 4:35 AM To: boost@lists.boost.org Subject: [boost] Re: Boost.Threads: Do we need all those mutexes? Batov, Vladimir wrote: three
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 constructor: condition c; void f(mutex m) { mutex::scoped_timed_lock l(m, locked); //always want the lock here for(;;) { //do stuff c.timed_wait(l, next_wakeup_time()); //timed_wait requires a timed_lock } } Mike _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Batov, Vladimir wrote:
According to the current Boost.Threads documentation timed_wait() does not require timed_lock (cut and pasted from http://www.boost.org/libs/thread/doc/condition.html#class-condition):
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) { if (!lock) throw lock_error();
return do_timed_wait(lock.m_mutex, xt); }
What am I missing?
My mistake. I had simply forgotten that timed_wait didn't require a timed lock, and didn't check before I posted.
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 nothing threads-related.
At the bottom of the page is a menu labeled "Show files using tag:". Choose "thread_dev" in the menu. (You'll have to navigate to the boost/thread or libs/thread directory before this option appears in the menu, since that branch was only created for those two directories and their subdirectories. BTW, ignore the thread_development branch, which is old.
Thanks, V.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Michael Glassford Sent: Friday, 2 July 2004 4:35 AM To: boost@lists.boost.org 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 lock(m, t=infinity)?
[Batov, Vladimir] Because, in my view, it violates the fundamental
(and
I think widely accepted) OO design principle (guideline?) that in
simple
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
(lock,
timed_lock and try_lock) or by keeping those three completely
unrelated
(probably at the expense of some code/functionality duplication). I am personally leaning towards latter, as even though technically all
three
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
constructor:
condition c;
void f(mutex m) { mutex::scoped_timed_lock l(m, locked); //always want the lock here
for(;;) { //do stuff
c.timed_wait(l, next_wakeup_time()); //timed_wait requires a timed_lock } }
Mike
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (4)
-
Batov, Vladimir -
Michael Glassford