Re: [boost] read_write_mutex fundamentally broken in 1.33?

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2005-09-09 15:30:28

John Maddock schrieb:

>The trouble is what do we do with 1.33.1?  We could either revert to the 
>1.32 version (if that is actually reliable, the current regression tests 
>don't show up these problems so we don't really know), or we could yank it 
>out of Boost entirely.  I'm leaning towards yanking it out at present, but 
>it's a drastic step, and this presupposes that the original authors of the 
>class can't temporarily fix things for 1.33.1 (they all look to have either 
>gone away or be too busy at present however).
>
>What do other folks think?
>
>  
>
I don't know either whether someone relies on the presence of rw mutex 
being in the
boost. However if he/she is using it, the usage itself is dangerous anyhow.

In my opinion it is better to omit it until it is fixed.

I am also not in the mood to dig through the sources to find out how the 
design was
intended to work. I would also vote for basing the design on a 
theoretically sound
ground (not claiming the current is not) that is understandable too.

While trying to find out the reason for the initial reported bug I found 
myself in a
maze of hard to understand details. Perhaps it would even be better not 
to base
the rw mutex on level 0 primitives only, but write it to the native API 
of the
respective platform?

Also I can think of a logical extension of the interface to "restricted 
group mutexes", where
there are multiple groups of privileges. At most n presetable members of 
a certain group
are allowed to hold the mutex at the same time.  The rw mutex is just a 
special case in
this scenario. I didn't spent much time yet trying to find out if this 
concept could benefit
from template partial specialization too, to provide optimizations for 
certain common
cases. But this definitely needs much more thought!

BTW.: I think we should instead put more effort to the level 0. Only 
recently I have
seen some requests on the user list to get access to the locking 
primitives from various
other parts of the library that are in detail currently.

Regards,
Roland