
Peter Dimov wrote:
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.
Sorry, the context doesn't make it clear but my paragraph above referred to the timed_mutex class 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. I wasn't referring to mutex::timed_lock at all.
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.
I have to say that I'm not too keen on the idea of an optional timed_lock() member function that only exists if it can be implemented efficiently, but that's another discussion.
The idea is that our C++ mutex should always be competitive with the "best" native mutex available on the platform.
It's hard to disagree with this.
(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.)
Yes, and I hope to look into it when I get time. Mike