From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-07-15 10:17:19
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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk