[boost] Re: Boost.Threads: Do we need all those mutexes?

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 
failed.

-Howard