java.io.File field "path" is not declared final

[Vitaly Davidovich]

Actually, I don't even think a volatile write helps here - it doesn't
prevent a subsequent (data racy) publishing of the instance from moving
before the volatile write.  It'll probably work in practice, but isn't JMM
compliant, so to speak.

Sent from my phone
On Feb 17, 2012 8:55 AM, "Vitaly Davidovich" <vitalyd at gmail.com> wrote:

> Why not just have one putObjectOrdered for the path as the last action in
> deserialization? I think a volatile store is overkill here.
>
> Sent from my phone
> On Feb 17, 2012 7:54 AM, "David Holmes" <david.holmes at oracle.com> wrote:
>
>> On 17/02/2012 10:41 PM, Alan Bateman wrote:
>>
>>> On 17/02/2012 12:37, David Holmes wrote:
>>>
>>>> On 17/02/2012 10:11 PM, Alan Bateman wrote:
>>>>
>>>>> On 17/02/2012 12:00, Rémi Forax wrote:
>>>>>
>>>>>> :
>>>>>> Better with the attachment inlined :)
>>>>>>
>>>>> Thanks Rémi, this looks okay to me although I probably would have used
>>>>> putObjectVolatile for the path field.
>>>>>
>>>>
>>>> You only need one "volatile" store and it should be the last one. The
>>>> approximate affect is:
>>>>
>>>> path = ...
>>>> membar: LoadStore | StoreStore
>>>> prefixlength = ...
>>>> membar: StoreLoad
>>>>
>>> I understand, I just remarking that I probably would have used a
>>> volatile store for both to make it clearer but that would be less
>>> efficient.
>>>
>>
>> For completeness I'll add that if only using one volatile store then it
>> needs to be prefixlength. The reason being that the freeze action on final
>> fields requires a storeStore barrier "at the end of the constructor" (or
>> deserialization in this case) - or more specifically it needs it after
>> setting all final object references. If the path setting was the only
>> volatile and came last then the storestore barrier would be in the wrong
>> place.
>>
>> David
>>
>>  -Alan
>>>
>>