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
bool timed_lock( xtime xt );
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. ;-)
> template <class Mutex>
> operator==(const scoped_lock<Mutex>&, const Mutex&);
> template <class Mutex>
> 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
> 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.
>> 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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk