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

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
{
private:

    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
std::tr2::lock<M>.

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.
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/
> 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
alternative:"

http://lists.boost.org/MailArchives/boost/msg64648.php

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

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