Re: Question whether a problem with race conditions exists in this case
On Dec 16, 1:38 am, Daniel Pitts
<newsgroup.nos...@virtualinfinity.net> wrote:
Hmm, actually, now I think I do... Its kind of a transaction thing,
isn't it?
Hi Daniel, the AtomicBoolean ist not needed any more in my second
approach where useNewValue is protected by the switchOverLock lock.
But it has to be an object, of which the value can be changed by
reference when the commit is to be donne atomically "in one go" for
all nodes, which cannot be done with java.util.Boolean since it is
constant. I would have to create own MyChangeableBoolean class. Looked
to me like an overkill and therefore held on to that AtomicBoolean
instance. For the real thing I need to add a comment explaining this
or create that MyChangeableBoolean class ;-)
Basically, you want to commit a change only under some circumstance, and
you want the "last to set before they commit" to win on commit.
Hmm... Interesting. Have you looked at AtomicReference, or
AtomicStampedReference? I think they do exactly what you're trying to do.
I had a short look at AtomicStampedReference. Maybe it was too short
and I should have a closer look at it.
AtomicStampedReference<V> reference;
public void process() {
final int[] stampHolder = new int[1];
final V oldValue = reference.get(stampHolder);
V result = doSomeProcessing(oldValue);
// commit phase:
reference.compareAndSet(oldValue, result, stampHolder[0],
stampHolder[0]=
+1);
}
Yes, I see. Problem is that there is a list of SwitchableValues
(because several changes were made in the transaction) and they all
need to switch values "in one go" for the commit to be atomic, e.g.
all changes of the transaction become visible at once or not at all.
Have to see whether this can be done with such an
AtomicStampedReference.
The reason you might want Stamped is in the following situation:
Thread 1 grabs value "A".
Thread 2 grabs value "A".
Thread 1 uses CAS for "A" to "B", so value is now committed as "B"
Thread 3 grabs value "B"
Thread 3 uses CAS for "B" to "A", so value is now committed as "A"
Thread 1 uses CAS for "A" to C". The result is different for stamped v=
s
unstamped...
Stamped, the result is "A" remains the value (because the stamp has
changed so the CAS fails). For unstamped, the value is "C", because th=
e
old value was "A".
Decide on which outcome you care about in that approach, in order to
decide whether to use Stamped or not.
This is interesting. Have to go to work now and will have a closer
look at it later.
Regards, Oliver