Re: Question whether a problem with race conditions exists in this
case
On 12/14/11 11:54 AM, Saxo wrote:
On Dec 14, 7:53 pm, Daniel Pitts
<newsgroup.nos...@virtualinfinity.net> wrote:
If it is always false, why pass it in at all? I don't believe this comment.> this.useNewValue = useNewValueParam;
It is passed in so that the visibility change from previousValue to
newValue can be done with a single atomic change of useNewValue by
reference from outside the synchronized block for all nodes in the
list at once. This is also the reason why boolean wouldn't work as not
accessible by reference and why it has to be aAtomicBoolean as the
commit thread changing the value of useNewValue does not enter the
synchronized block.
The threads are all serialized because of the synchronize(lock).
This is true for all threads calling aNode.get(), but not for the
single commit thread that changes useNewValue atomically by reference
from outside the synchronized block.
This sounds like the wrong reason to use AtomicBoolean, but perhaps I'm
not understanding your use-case.
Hmm, actually, now I think I do... Its kind of a transaction thing,
isn't it?
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.
<http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/atomic/AtomicReference.html>
<http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/atomic/AtomicStampedReference.html>
For example:
AtomicReference<V> reference;
public void process() {
final V oldValue = reference.get();
V result = doSomeProcessing(oldValue);
// commit phase:
reference.compareAndSet(oldValue, result);
}
OR, if you need to only commit if there haven't been *any* other changes:
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);
}
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 vs
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 the
old value was "A".
Decide on which outcome you care about in that approach, in order to
decide whether to use Stamped or not.