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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
