Re: [boost] Re: Boost.Threads: Do we need all those mutexes?

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-07-15 09:31:15

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.)