Boost logo

Boost :

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
> from
> 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
> 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 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, gregod at, cpdaniel at, john at