Path: csiph.com!usenet.pasdenom.info!gegeweb.org!eternal-september.org!feeder.eternal-september.org!mx05.eternal-september.org!.POSTED!not-for-mail From: markspace Newsgroups: comp.lang.java.programmer Subject: Re: Usefulness of "final" (Was: Re: Inserting In a List) Date: Wed, 03 Apr 2013 17:19:17 -0700 Organization: A noiseless patient Spider Lines: 62 Message-ID: References: <19un43xj77bua.vw45l4e2wshi.dlg@40tude.net> <1m6qixygl0s9c$.1fv60gxfuhuyz.dlg@40tude.net> <117qwc9w50mtb.1aizwvzf7bigo.dlg@40tude.net> <1rb5a1rqvwu96.4bxnq45wdqe8.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Thu, 4 Apr 2013 00:16:55 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="fba3415ba68d85d643935af2f52f0b4b"; logging-data="9581"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19byvjqIqu5OrNnT8ETWs09NElMQKCzfa0=" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 In-Reply-To: <1rb5a1rqvwu96.4bxnq45wdqe8.dlg@40tude.net> Cancel-Lock: sha1:eoUMhh3CfAy/aDHFMEr5YT7AKhQ= Xref: csiph.com comp.lang.java.programmer:23254 On 4/3/2013 4:57 PM, Joerg Meier wrote: > That initial write is not synchronized to other threads. Yes it is! (Not immediately synchronized, at the end of the ctor.) Read the JLS, besides the part I quoted above: "Let o be an object, and c be a constructor for o in which a final field f is written. A freeze action on final field f of o takes place when c exits, either normally or abruptly.... Given a write w, a freeze f, an action a (that is not a read of a final field), a read r1 of the final field frozen by f, and a read r2 such that hb(w, f), hb(f, a), mc(a, r1), and dereferences(r1, r2), then when determining which values can be seen by r2, we consider hb(w, r2). (This happens-before ordering does not transitively close with other happens-before orderings.) " That's as clear as mud, but what it means is that objects referenced by final fields, and all writes to those objects, are made visible at the end of the object's ctor. > If > you let an object instance get out that isn't fully constructed, then you > will get the usual synchornization issues, final or not. Don't believe me ? This is true. If the final field object escapes from the enclosing class, or any writes are made after the object is constructed, then both immutability and thread-safety are broken. > If I misunderstood, and you believe that structural changes to the > ArrayList would be visible to all threads, then you are still wrong, In the second example you gave where the reference to 'stooges' leaves the enclosing class, it is definitely neither immutable nor thread-safe. > The mere use of final does not remove the need for synchronization. Yes it does! That was explicitly stated in the very short bit I quoted at the beginning of this whole mess. > Nor > does the mere lack of it dictate a need. No. 'final' is special here. > The reason synchronization is not > needed with proper immutability is an effect from what final does - because > it can only be assigned once, once it is you can then let everyone play > with it, because you dont NEED to worry about writes - there will be none. No, you still need to, at a low level, insert a memory barrier to make those writes visible. You'd need to use synchronization or a volatile variable or some other synchronization in Java, or you could see a partially constructed object. Just like any regular object that doesn't use final or volatile fields. Also, go read Java Concurrency in Practice by Brian Goetz. He covers this in some detail (complete with Stooges example).