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

[Rémi Forax]

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