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.
The company I am working for is actually using timed rw mutex on a current project (and they seem to be working), so I for one would like them to stay in. I suspect timed locks aren't going to deadlock?
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?
How should we proceed from here? Should the community come up with a list of alternative implementations that could be evaluated and used as a starting point? Or do we need to go back a step further and decide what types of mutexes or primitives are actually desired?