From: William Kempf (sirwillard_at_[hidden])
Date: 2000-09-14 10:42:25
--- In boost_at_[hidden], Csaba Szepesvari <szepes_at_m...> wrote:
> William Kempf wrote:
> > In any event this example likely leads to a race condition! f()
> > modify a in a way that will invalidate the call to next()!
> > (Arguments that it doesn't don't hold water with me, since later
> > maintenance may change that.)
> However, this is like saying that whatever example you give that
> will induce race conditions.
> You have to leave with race conditions!! You have to think about
> design your programs. Don't tell me that you can design interfaces
> way that do not leave any space for race conditions.
> You could say that you substantially reduce the number of race
> with your design but it is simply not the case as the example of
> shows - you could say, he is misusing your interface, but I do not
The example screams that we'll have race conditions, while in general
simply unlocking a mutex does not. Unlocking a mutex that controls a
container in the middle of iterating over it simply is bad design.
My point was solely that his example needed further thought...
thought which you were forced into doing because of the design of the
interface. You can still code precisely what he had (ahem...
unsafe_lock<>) with the current interface, but you're forced
(psychologically) into thinking about it before doing so.
> > There are numerous ways to refactor this example, and it really
> > refactoring. Probably the safest solution is to take a hint from
> > Java here and "enumerate" a by taking a (thread safe) snapshot of
> > in a locally controlled copy which can be safely iterated over,
> > if a were to be modified by f().
> Sometimes this is not an option.
Agreed, but at this point you're discussing micromanagement of
optimizations. I refuse to compromise safety for such corner
cases... especially when a usable alternative (ahem... unsafe_lock<>)
can easily be employed using the existing interface.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk