On Dec 15, 2010, at 1:31 AM, John Rose wrote:
> On Dec 13, 2010, at 12:19 AM, Rémi Forax wrote:
>> On 12/12/2010 05:02 PM, Rich Hickey wrote:
>>> Rémi's synchronized block only coordinates the activities of
>>> updaters.
>>> Other threads may, and in some cases may have to, see some of the
>>>
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 m
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. -- J
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
> }
On Dec 15, 2010, at 2:27 PM, Rémi Forax wrote:
>> 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.
Foo; I agree. The T1 update
