From: Howard Hinnant (hinnant_at_[hidden])
Date: 2004-07-13 13:47:11
On Jul 13, 2004, at 12:06 PM, Peter Dimov wrote:
> Yes, having both mutex and timed_mutex will satisfy our hypotheticals.
> However if mutex::timed_lock is required, timed_mutex makes no sense
> specification point of view.
My bad. There are at least 3 important clients to consider:
1. Give me mutex::timed_lock(), but only if it doesn't cost much, else
I want a compile time error.
2. Give me timed_mutex::timed_lock(). Gotta have it on every platform.
3. Give me mutex::lock(), and please make it as small and fast as
possible. I'm putting this mutex into my objects, and I'll have
container<my_object>, so minimal overhead in the mutex is important (I
don't care about timed_lock(), never use it).
Did I miss any? Have I enumerated any "clients" that anyone thinks
don't exist, or exist in vanishingly small numbers? Personally I feel
that 2 and 3 definitely exist in significant numbers. I'm not positive
about 1, but readily admit that I wouldn't want to bet much that 1
exists in vanishingly small numbers.
> I want the standard to require mutex::timed_lock, because if there is
> such requirement, no implementation will provide it. Why bother? No
> are taken off conformance tests, and the users can't really demand it,
> because it's not required.
I think you grossly understate the motivation of all the std::lib
vendors I'm aware of today. While the Metrowerks implementation is
quite clearly the best one available, ;-) all implementations are
aggressively pursuing conformance, optimizations and extensions. I'm
not aware of any mediocre implementations of the std::lib today
(compared with say 7 years ago). And I'm also not aware of any
std::lib vendor that isn't listening very closely to their customers.
My compliments to my competitors.
If an optional mutex::timed_lock() is a good idea, and if C++0X blesses
the idea, and if a few customers of a specific vendor request it for a
specific platform where it would indeed make sense, I can practically
guarantee you it will be implemented.
If on the other hand, mutex::timed_lock() is required, I can guarantee
you that customer #3, on some platforms, is going to be a very unhappy
camper. Unhappy enough to not use this library, and thus we will have
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk