Re: Question whether a problem with race conditions exists in this
case
On 12/14/2011 4:57 PM, Saxo wrote:
On Dec 14, 10:26 pm, Eric Sosman<esos...@ieee-dot-org.invalid> wrote:
[...]
What's the larger problem you're trying to solve?
Well, I'm basically thinking about how to implement a database commit.
I don't use a database. Instead, the data is on the heap in a simple
list. When the commit is done, all the new values in all the nodes in
my list become visible at once (by changing useNewValue as explained)
to any thread calling get(). This way I get around changing the values
in a big big synchronized block which would cause quite some lock
contention.
You'll still have the problem that threads T1 and T2 could get()
different values from the same Node, and both be working with those
conflicting values at the same time. An "instantaneous" change will
not avoid the issue -- so either (a) it better not be an issue, or
(b) you need The Mother Of All Locks around the whole shebang ...
Also, the problem ordinarily addressed by a "commit" mechanism
is somewhat different: You want to make changes to Nodes N1 and N2,
and you want to make sure an observer sees either the two old values
or the two new values, but never a mixture. Again, "instantaneous"
change won't solve the problem, not even in the simple case of just
one mutator and one observer:
Observer: Fetch the N1 value, then ...
Mutator: CHANGE THE WORLD INSTANTANEOUSLY
Observer: ... fetch the N2 value
For the observer's view of N1 and N2 to be consistent, it's not
enough that each get() be guarded against interference; you need
the pair of get()'s guarded as a unit. Very likely, you also need
the changes to N1 and N2 guarded as a unit.
--
Eric Sosman
esosman@ieee-dot-org.invalid