Re: [boost] read_write_mutex fundamentally broken in 1.33?

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2005-09-09 08:15:01

On Sep 9, 2005, at 5:32 AM, Ion Gaztañaga wrote:

> http://home.twcny.rr.com/hinnant/cpp_extensions/threads_move.html
>
> Do you have more information about these concepts and their use? It
> seems quite interesting for thread proposals.

The "performance testing" link off of the above page has example code:

http://home.twcny.rr.com/hinnant/cpp_extensions/rw_perf.html

>  Currently in boost we have
> the following:
>
> scoped_lock, scoped_try_lock, scoped_timed_lock

Right.  And I went this route too (following boost's lead).  But 
hindsight is 20/20. ;-)  The scoped_lock, scoped_try_lock, and 
scoped_timed_lock concepts are all strict supersets of one another (and 
this is good).  You can code a scoped_timed_lock, templated on the 
mutex type, and use it only as a scoped_lock with absolutely zero 
penalty.  There is no extra data associated with a scoped_timed_lock 
over a scoped_lock.  And the code associated with timed locking isn't 
instantiated unless you use it.

Said another way, you can get rid of the template classes scoped_lock 
and scoped_try_lock, and rename scoped_timed_lock to scoped_lock, and 
then use this new "combined" scoped_lock for all three uses.  You will 
pay no penalty in code size or speed, and you will cut your source code 
maintenance by a factor of 3.

If you instantiate this new "combined" scoped_lock with a mutex that 
can not execute a timed_lock (for example), absolutely no harm is done 
... unless of course the client of this instantiation actually tries to 
call timed_lock, in which case you would quite naturally get a compile 
time error.

Analogy:  std::vector doesn't require a default copy constructor of its 
contained type, unless you actually instantiate certain member 
functions of vector.

My scoped_lock doesn't require the mutex to have a timed_lock() member 
unless you instantiate the timed_lock() member of the scoped_lock.

So my scoped_lock is simply the boost scoped_lock, scoped_try_lock, 
scoped_timed_lock rolled into one class.

> Your web talks about upgradeable, shareable, so maybe we could think
> about this when thinking about C++ threading interface.

The rw_perf.html page gives motivation for the read/write - renamed to 
scoped/sharable - and for adding the upgradable concept as well.  The 
sharable and upgradable locks all meet your scoped/try/timed concepts, 
but do not demand these concepts of the mutex.

> I suppose Kevlin
> Henney is thinking about this issues regarding its C++ Threading
> interface proposal, so maybe these concepts are interesting.
>
> Alexander Terekhov's algorithm seems interesting, so we decide to go
> ahead with this, we should implement it on top of some boost atomic
> primitives.

<nod> See the performance link for a few notes on this (but there is no 
implementation posted there, only notes).

-Howard