From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-07-13 11:06:02
Howard Hinnant wrote:
> How do we serve the client who needs a timed mutex, on every platform,
> and would rather not implement it himself? If mutex::timed_lock
> sometimes compiles and sometimes doesn't, then that isn't the answer.
> And telling the client that he can just emulate this functionality
> himself is no different than telling him he can just emulate the STL
> himself. The emulation on platforms with non-native support requires
> a certain amount of expertise, careful coding, and most importantly,
> time. Must everyone who must have a timed mutex become an implementor
> of it?
Probably not, _if_ this hypothetical client exists. I don't doubt it that
once you provide a timed_mutex, many will find it useful, with or without
quotes. But the mutex+condition underneath will probably mean that these
users are not getting their money's worth from the design. If they
explicitly see the monitor pattern hidden under the opaque timed_mutex, they
might be able to put it to better use.
> I don't have a problem if mutex is allowed to optionally sport a
> timed_lock() member function (presumably only if it could do so with
> "acceptable" cost). I just don't want to require it to (in case the
> costs are deemed "unacceptable").
I want the standard to require mutex::timed_lock, because if there is no
such requirement, no implementation will provide it. Why bother? No points
are taken off conformance tests, and the users can't really demand it,
because it's not required.
> I'd rather there exist a timed_mutex class with that requirement.
> Would this not satisfy both of our hypothetical clients?
Yes, having both mutex and timed_mutex will satisfy our hypotheticals.
However if mutex::timed_lock is required, timed_mutex makes no sense from
specification point of view.
Anyway, (mutex with try_lock and optional timed_lock + timed_mutex) * 2 +
static_mutex would still be better than (mutex + try_mutex + timed_mutex) *
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk