Path: csiph.com!eeepc.pasdenom.info!news.pasdenom.info!news.dougwise.org!news-transit.tcx.org.uk!news.glorb.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!newsfe03.iad.POSTED!00000000!not-for-mail From: Owen Jacobson Newsgroups: comp.lang.java.programmer Message-ID: <2011021122255478329-angrybaldguy@gmailcom> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: boolean and thread safety User-Agent: Unison/2.1.3 Lines: 87 X-Complaints-To: abuse@UsenetServer.com NNTP-Posting-Date: Sat, 12 Feb 2011 03:25:54 UTC Date: Fri, 11 Feb 2011 22:25:54 -0500 Xref: csiph.com comp.lang.java.programmer:25878 On 2011-02-11 14:24:36 -0500, Daniele Futtorovic said: > On 11/02/2011 19:09, raphfrk@gmail.com allegedly wrote: >> Are booleans inherently thread safe? >> >> I am thinking of something like >> >> public class AsyncBoolean { >> >> boolean value = false; >> >> public AsyncBoolean(boolean initValue) { >> value = initValue; >> } >> >> public boolean getValue() { >> return value; >> } >> >> public void setValue(boolean value) { >> value = newValue; >> } >> >> } >> >> Assuming I define the variable using >> >> final AsyncBoolean varName = new AsyncBoolean(true); >> >> does this in effect auto-sync, since you can't partially read a byte >> and even if you could it is a boolean anyway? >> >> Since it is declared as final, the reference can't change, so I could >> then call varName.setValue(someValue) and varName.getValue() from >> threads without the need for syncing. > > You're mixing different things here. *Assigning* a boolean value, as in > value = true > is atomic, and hence thread-safe. > > But what thread safety is about is only marginally atomicity (because > all assignments save those of double and long variables are atomic). The > main point is what a thread "sees". That is, whether it "sees" the > changes operated by another thread. Not only that, but also in *what order* other threads see changes. Given shared non-volatile boolean fields 'startedWork' and 'finishedWork' both initially false and no memory barriers (volatile, synchronization, or otherwise), if Thread #1 executes foo.startedWork = true; /* ... some work ... */ foo.finishedWork = true; then Thread #2 may legitimately print "Can't happen!" from if (foo.finishedWork && !foo.startedWork) { System.out.println("Can't happen!"); } even though Thread #1 ensures that foo.finishedWork only becomes true after foo.startedWork is true. While this is relatively easy to diagnose when both writes (and reads) affect closely-related shared fields, the same surprising behaviour can arise from unrelated objects and writes (reads) separated by large stretches of code. Adding memory barriers or using AtomicFoo types not only ensures that changes will be seen but also ensures that the changes will be seen in a predictable order. The Java memory model (defined at the end of the JLS) lays out the specific guarantees for various scenarios. > With respects to that, no primitive type, no matter how small, is > thread-safe. You'll have to ensure synchronisation of information across > threads. The easiest way to do that, assuming the propagation of the > reference to the "AsyncBoolean" instance is ensured, would be to declare > the "value" field /volatile/. Another way would be to synchronise in the > getter and setter. > > Have a look at java.util.concurrent.atomic.AtomicBoolean. All good advice. I'll throw another vote on "read Java Concurrency in Practice", too. -o