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

[Vitaly Davidovich]

Nevermind, the storestore barrier won't be in the right place.  Where's
that Fences API? :)

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
>>>
>>