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" <[email protected]> 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" <[email protected]> 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 >>> >>
