Date: 2005-09-09 23:01:04
>>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
>>out of Boost entirely. I'm leaning towards yanking it out at present,
>>it's a drastic step, and this presupposes that the original authors of
>>class can't temporarily fix things for 1.33.1 (they all look to have
>>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
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk