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) * 2.