Re: thread lock/unlock example

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() 
may
> > 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 
unlocks
> will induce race conditions.
> You have to leave with race conditions!! You have to think about 
those,
> design your programs. Don't tell me that you can design interfaces 
in a
> way that do not leave any space for race conditions.
> You could say that you substantially reduce the number of race 
conditions
> with your design but it is simply not the case as the example of 
Levente
> shows - you could say, he is misusing your interface, but I do not 
agree.

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 
needs
> > refactoring.  Probably the safest solution is to take a hint from
> > Java here and "enumerate" a by taking a (thread safe) snapshot of 
it
> > in a locally controlled copy which can be safely iterated over, 
even
> > 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.

Bill Kempf