[jvm-l] Re: request for advice: safepoints in the JSR 292 spec

[Rich Hickey]

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