[concurrency-interest] 3 rules of final field semantics
radhakrishnan.mohan at gmail.com
Fri Dec 30 00:14:54 EST 2011
Ok. I got the point about traversal through a reference chain starting
with a final field and not a non-final field.
On Tue, Dec 27, 2011 at 3:53 PM, Ruslan Cheremin <cheremin at gmail.com> wrote:
> My point was about this: final fields semantic is very precise.
> Additional happens-before edges it brings into JMM are guaranteed only
> for very specific kind of usages. Moreover, such HB edges are _not
> transitive_ -- so you can't spread ordering them gives you farther by
> merging them with program-order HB edges, and other ones (as it
> usually can be done with ordinary HB -- which _are_ transitive).
> So far, final field semantic (as far, as I do understand them)
> guarantee you what if you have object A with final field f, and:
> 1) You publish reference to A "correctly" -- which, here means "
> 'this' does not escape from A's constructor"
> 1) You have got reference to A in some other thread
> 2) Then, going through reference chain _starting from A.f_ (this is
> important!) you'll guaranteed to see any stores, finished before A's
> constructor completed (before freeze).
> In your rele 2 example you trying to see stores, finished before
> freeze, but you trying to see them through non-final A's field. AFAIK,
> JMM gives you no additional guarantee in this case.
> 2011/12/27 Mohan Radhakrishnan <radhakrishnan.mohan at gmail.com>:
>> I was thinking that this
>> v.afield = 1;
>> finalField = v;
>> rule2 = new FinalRule2(); //sharedref
>> is equivalent to
>> v.afield = 1; x.finalField = v; ... ; sharedRef = x;
>> Earlier I was thinking that we are not concerned with patterns like
>> this because Java takes care of it !
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest