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