Re: [boost] Re: thread lock/unlock example

From: Csaba Szepesvari (szepes_at_[hidden])
Date: 2000-09-14 10:38:22

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.

Design, design, design.. and documentation.

>
> 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.

> > create the lock on the heap can't help here.
>
> And why not?
>

But it would, I agree with Bill.

- Csaba