[concurrency-interest] 3 rules of final field semantics

Ruslan Cheremin cheremin at gmail.com
Tue Dec 27 05:23:28 EST 2011


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 !
>
> Thanks,
> Mohan
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



More information about the Concurrency-interest mailing list