Michael Glassford wrote: [...]
The difference in the pthreads case is a difference in the data that must be stored in the Boost.Threads mutex object: each one needs to store both a mutex and a condition variable, though I suppose--at the expense of requiring the storage to be dynamically allocated--space for the condition variable could be allocated only on platforms that don't support pthreads_timedlock.
No, no. The goal of mutex::timed_lock is not to cripple the mutex by turning it into a monitor. This is unacceptable. The goal is to provide an efficient timed_lock. If there is no efficient timed lock available on the platform, there should be no mutex::timed_lock. The argument we had with Howard is not about the above, on which we - hopefully - agree. The argument was about whether, from standard point of view, an implementation that doesn't provide mutex::timed_lock should be conforming. It is mostly a specification/theory/philosophy issue. In practice, the rule is simple. Have _POSIX_TIMEOUTS -> will travel, er, will have pthread_mutex_timedlock and mutex::timed_lock. The idea is that our C++ mutex should always be competitive with the "best" native mutex available on the platform. (Incidentally, on Windows, the best native mutex is neither CRITICAL_SECTION nor HMUTEX, it's Alexander's event-based thing. Or so he says. But he's usually right about these things.)