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

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2004-07-12 19:01:14

On Jul 12, 2004, at 4:39 PM, Peter Dimov wrote:

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

Sorry, I missed the "private" declaration.  And I like the idea of 
standardizing the interface for the purpose you state.  I'd be tempted 
to make them public so that they could be used outside of a lock, or 
with user-written locks.  (e.g. someone writes a read/write lock that 
is better than what we're dreaming of).

We can still standardize an interface, but not require the entire 
interface.  E.g. here's what you must have:

void lock();
void unlock().

And if you want to try-lock, you have to also provide:

bool try_lock();

And if you want to provide timed-locks...
And if you want to provide read-lock...
And if you want to provide write-lock...
And if you want to provide upgradable-read-lock...

Personally I'm a little giddy over the try-timed-upgradable-read-lock, 
but hey, it could really be useful in just the right circumstance.  But 
I wouldn't want to pay for that if I just needed a simple lock.

Who knows, there might even be an application for a read (but not 
write) lock?  Everybody can concurrently access this structure, but you 
must "register" yourself first by obtaining this read-lock...  <shrug>  
no practical application in mind, just brainstorming.

And then there's recursion, same interface but slightly different 
functionality... maybe:

class Im_a_recursive_mutex
{
public:
        typedef int recursive;
      ...
};

?

Nested types can be detected at compile time, so clients (locks or 
whatever) can figure out what they're dealing with (and a helpful 
utility traits provided to do this).

We provide an extendable mutex concept that can plug & play with an 
extendable lock concept, provide a few example mutexes and locks, and 
turn the world loose on it to continue the work?

> [...]
>
>> 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.

Yeah, but with prettier spelling. ;-)

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

<nod> good points.  Perhaps all 6 relationals should be added to the 
(public) basic mutex interface?  In C++0X if containers are move-aware 
and mutexes movable, then you could then map<mutex, ...>.

> 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

<nod>  I truly appreciate Alexander's continued willingness to publish 
algorithms such as this.  Thanks Alexander!

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

<sigh>  It isn't just Mac OS X either.  There are other (embedded) 
platforms I've neglected to mention because I'm not positive exactly 
what my NDA is.  But it can get pretty ugly out there in some cases.  
If OS's would just adopt the pthreads knowledge and experience the 
world would be such a better place.  Multithreading is a tough area and 
OS designers aren't necessarily experts in that particular area (and 
I'm not claiming to be either).  And without the proper OS 
functionality, add-on threading libraries are inherently limited. ... 
No point I'm trying to make.  Just being grumpy. ;-)

-Howard