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