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

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