On 26 February 2013 12:20, Dan Creswell <[email protected]> wrote: > On 26 February 2013 12:08, Patricia Shanahan <[email protected]> wrote: >> On 2/26/2013 3:05 AM, Dan Creswell wrote: >> ... >> >>> Final of course meaning nothing other than "value won't change" - a >>> compile/language level guarantee. >>> >>> It doesn't interact in any meaningful way with the JVM concurrency >>> mechanics. i.e. it doesn't have any relationship to a synchronization >>> action (or barrier as I prefer). Thus final provides no multi-thread >>> guarantee explicitly. What one can say is that once the value becomes >>> visible to a set of threads it won't change. >> >> ... >> >> How do you view the following JLS section 17.5 Final Field Semantics? >> http://docs.oracle.com/javase/specs/jls/se5.0/html/memory.html#66562 >> >> In particular, that section says "An object is considered to be completely >> initialized when its constructor finishes. A thread that can only see a >> reference to an object after that object has been completely initialized is >> guaranteed to see the correctly initialized values for that object's final >> fields." > > I think the key phrase is "a thread that can only see a reference to an > object". > > If you were the thread that did the creation, you have a reference and > final's must be initialised by end of construction thus you are > guaranteed to see the correct values. > > If you were another thread, the only way you could get that object > reference is via some synchronisation barrier/action (which flushes > any values sitting in a core cache and makes them visible to all > processor cores). At this point you have a valid object reference and > all the initialisation done in the constructor has also been made > visible to you by the flush. This, to me, is the implicit unwritten > element of the above specification. > > Final just means "at end of construction this field will be > initialised and not change". >
Or put another way: final is a guarantee of when initialisation will have been completed from the point of view of the caller of new and the implementer of the class. It says nothing about the memory/core visibility of that initialisation. > >> >> Patricia >> >>
