Michael Glassford wrote:
Sorry, the context doesn't make it clear but my paragraph above referred to the timed_mutex class...
I see; yes, in this case, you are right that timed_mutex needs to continue holding a mutex and a condition variable in the general case. There is no need to allocate a condition variable dynamically, however, as the existence of pthread_mutex_timedlock is a compile-time thing.
... which, according to what I remember of your discussions with Howard, you (?) suggested would implement a timed lock regardless of whether it was supported by the platform and regardless of whether it could be implemented efficiently.
No, I did not suggest that; this is simply the current status quo, which Howard likes to see preserved. I suggested removing timed_mutex from the specification, leaving it in the implementation only to support backwards compatibility. My argument was that forcing the user to explicitly spell the mutex+condition combination hidden by the timed_mutex may prompt said user to reevaluate and improve the design, but this may be overly optimistic.