Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!nuzba.szn.dk!pnx.dk!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: Usefulness of "final" (Was: Re: Inserting In a List) Date: Sat, 06 Apr 2013 13:31:27 +0200 Lines: 81 Message-ID: References: <19un43xj77bua.vw45l4e2wshi.dlg@40tude.net> <1m6qixygl0s9c$.1fv60gxfuhuyz.dlg@40tude.net> <117qwc9w50mtb.1aizwvzf7bigo.dlg@40tude.net> <515cc4ef$0$32111$14726298@news.sunsite.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: individual.net iwMLYHaVCOP8cPk54DmDngZZyERX8QtfHVpBMArqg1CZ5WjIU= Cancel-Lock: sha1:Ep4XVtxttEKd+mKdIxGBcR8gvtc= User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 In-Reply-To: X-Antivirus: avast! (VPS 130405-1, 05.04.2013), Outbound message X-Antivirus-Status: Clean Xref: csiph.com comp.lang.java.programmer:23345 On 04.04.2013 02:29, markspace wrote: > On 4/3/2013 5:10 PM, Arne Vajh=F8j wrote: >> >> It can be very important in multithreaded context. >> >> But it is not what makes a class immutable. > > OK, that's true. The section I linked to refers to such objects as > "thread safe immutable." It's both concepts in one package. Objects > that aren't thread safe aren't immutable, and objects that aren't > immutable aren't thread safe. I guess that's why the two go together. I think there's too much mixed here. "Thread safety" and=20 "(im)mutability" are two different concepts. They are orthogonal -=20 albeit related because the latter can help to achieve the former.=20 Mutability itself is complex as I have tried to show elsewhere in this=20 thread. Then again thread safety is a much more complex concept. First of all, objects which are mutable can be thread safe - it depends=20 on their implementation. (J=F6rg pointed that out already). Then: you wrote "Objects that aren't thread safe aren't immutable". Now = this depends on what we mean by "thread safe". An immutable object's=20 state is guaranteed to be seen by all threads identical (given proper=20 coding, which might include the use of "final" fields and creation of an = instance before other threads are started OR handing it over to them in=20 a thread safe manner w.g. with a blocking queue which memory barriers=20 through its synchronization). But: that does not necessarily constitute thread safety. An immutable=20 object can still be implemented in a thread unsafe manner. For example: public final class KeyValuePairPrinter { private final PrintStream out; public KeyValuePairPrinter(PrintStream out) { this.out =3D out; } /** * Print a single line with key "=3D" value. * @param key key to print before equals sign * @param value value to print after equals sign */ public void print(Object key, Object value) { out.print(key); out.print("=3D"); out.println(value); } } Now, this class is immutable - but is it thread safe? I'd say no,=20 because there is no guarantee that key, "=3D" and value are printed on th= e=20 same line in a multithreaded environment. > final is required, but you also have to actually prevent any > modification to the object's state after it is constructed. It is a tw= o > part process, that is true. "final" is neither required nor sufficient for immutability AND thread=20 safety. For example, as long as you ensure there is a memory barrier=20 between construction and use of an instance final fields are not needed=20 to ensure other threads see the proper state. Thread safety usually=20 cannot be ensured by a single class. The typical example is=20 Collection.synchronizedMap(): if you use the typical pattern "test if a=20 key is present and if not add it to the Map" without explicit=20 synchronization the code is not thread safe even though the Map ensures=20 it's never modified at the same time by two threads and all threads see=20 all updates from other threads. There are many more examples like that. Kind regards robert --=20 remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/