On 12/15/2010 10:03 PM, Rich Hickey wrote:
On Dec 15, 2010, at 3:08 PM, John Rose wrote:
On Dec 15, 2010, at 7:04 AM, Rémi Forax wrote:
default generic method (reader):
synchonized(masterLock) {
// check arguments
// use meta data to create a fast path
}
(This next line should also be synchronized. -- JRR)
setTarget(guard + fastpath);
Correct me if I'm wrong.
Le last line can be in the synchronized block but it don't have to.
The JMM guarantees that the current thread will see the new target
(T2).
Other threads can see T1 and in that case will update to a T2' which is
semantically equivalent to T2.
It's a racy update.
Racy updates have the risk of not getting picked up by Slow Reader
threads.
But, as you point out, in this case T1 synchronizes any Slow Reader
and forces him to see T2.
So, you're right.
I guess the principle is that racy updates are OK as long as the
previous state (T1) is allowed and will eventually force all readers
to go to the new state (T2).
Why can't T3 happen between the synchronized block and the setUpdate
call, and get overwritten with a T1-based decision?
Rich
It can. I was wrong.
setTarget() has to be in the synchronized block.
Rémi
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
