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?