Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-07-12 15:39:58

Howard Hinnant wrote:
> On Jul 12, 2004, at 11:28 AM, Peter Dimov wrote:


> If we expose either a Mutex* or a Mutex&, and we standardize a public
> Mutex interface (with lock(), unlock(), etc.), then we are saying that
> one can call functions on the pointer or reference returned by mutex().
> And now that I write that sentence my skin is beginning to crawl. ;-)

This is what 'class mutex' looks like in my original message:

class mutex // DefaultConstructible

    void lock();
    bool try_lock();
    bool timed_lock( xtime xt );
    void unlock();

IOW, the function names are standardized, but they aren't public. The intent
is to allow users to write a mutex class M that can be used with

As a mutex doesn't have a public interface, the mutex() accessor cannot be
used to manipulate a lock's associated mutex.

It is, of course, possible to make this interface public, but I haven't
proposed that. ;-)


> Brainstorming:
> template <class Mutex>
> bool
> operator==(const scoped_lock<Mutex>&, const Mutex&);
> template <class Mutex>
> bool
> operator==(const Mutex&, const scoped_lock<Mutex>&);
> instead of Mutex* scoped_lock::mutex() const;
> ?

That's just my 'is_associated_with' with a different name. It's a bit more
limited than mutex(); for example, you can't use a map<void*, ...> keyed on
mutex(), and you can't compare l1.mutex() and l2.mutex() (using
std::less<void*>) to derive a locking order.

>> Do you have data on whether your platforms support
>> pthread_mutex_timedlock?
> I have one platform to support where I preferred a different
> implementation for mutex and try_mutex: Win98. Admittedly that one
> is quickly going obsolete. Nevertheless I currently still need to
> support it.
> dllproc/base/tryentercriticalsection.asp
>> TryEnterCriticalSection
>> Requires Windows XP, Windows 2000 Professional, or Windows NT
>> Workstation 4.0.

Have you seen Alexander's 'swap-based' implementation? The link was in my
original post, right after "It is true that Windows 95 does not have
TryEnterCriticalSection, but an implementation can use Alexander Terekhov's

> Mac OS X up through 10.3.4 (most current) does not appear to support
> pthread_mutex_timedlock, and so on this platform my mutex
> implementation differs from my timed_mutex implementation.

Not good. This means that you cannot be persuaded to abandon timed_mutex,
which in turn means that the future standard will probably have a
timed_mutex, even if at that future time Mac OS X does have

The alternative reality would have a mutex with timed_lock #ifdef'ed on
_POSIX_TIMEOUTS until conformance arrives.

Boost list run by bdawes at, gregod at, cpdaniel at, john at