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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-07-13 14:59:01

Howard Hinnant wrote:
> 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).

Almost. Client 1 is actually:

1a. Give me mutex::timed_lock that (if it) doesn't have a cost; that is, it
is as fast as mutex::lock in the non-blocking case, and it doesn't impose
performance penalties on mutex::lock, mutex::try_lock, mutex::unlock.

This is effectively the same as POSIX. OK, it may be "almost doesn't have a
cost", or "doesn't cost much", but the intent is clear.

In a perfect world, all platforms will have such a timed_lock, and all
clients would be happy. And our specification should not be suboptimal in
this world.

OTOH I appreciate your arguments. Even though pthread_mutex_timedlock may be
implementable everywhere, it's a fact of life that some platforms do not,
and will not, supply it. However if a platform has a timed lock that
satisfies (1a) then it should be exposed as mutex::timed_lock. I don't know
whether there's such a precedent in the standard library; nothing optional
comes to mind.

A problem with timed_mutex is that once it gets into the standard, it can't
be removed, even if it turns out that type (2) clients are few, or that
having a timed_mutex handy doesn't encourage careful design. Whereas the
reverse situation - no std::tr2::timed_mutex and customer revolt - is easily
fixable; you just provide it as an extension (something that Boost.Threads
will also need to do, BTW, even if we redesign the mutexes and the locks).
Since the interface is already specified by std::tr2::mutex, a hash_map
situation should not occur. ;-)

Hm. Where were we. Oh yes.

- mutex::timed_lock: optional.

- timed_mutex: in the std or not?

- recursive_mutex: in the std? Seems so.

- condition::wait with recursive_mutex: compiles?

- condition::wait with recursive_mutex locked more than once: defined? if
so, how?