I doubt it's case #2, there is a lot of complex code that runs between putThread.start() and putThread.done().
In terms of JVMs, I'm using Java 6 on OSX x64. HBase effectively requires Java 6 (and if we dont explicitly require it, we should) and it also specifically cannot use certain broken JVM pushes (eg: jdk6u18) so much that we are adding in code to prevent ourselves from running on it and warning the user. But just for a moment, I think it's inappropriate for the JVM to be specifying caching or non-caching of variables in the systems cache. That is way too much abstraction leakage up to the language level. Most SMP systems have cache coherency control that allow you to read from cache yet get invalidations when other processors (on other dies) write to that memory entry. But nevertheless, the problem no longer exists with AtomicBoolean :-) On Thu, Apr 15, 2010 at 5:05 PM, Paul Cowan <co...@aconex.com> wrote: > On -9/01/37 05:59, Ryan Rawson wrote: >> >> So the previous use of volatile for a boolean seems like a textbook >> case, but the situation i discovered was pretty clear cut. I have no >> other explanation than a highly delayed volatile read (which are >> allowed). > > I don't see that they are allowed, actually. > > Section 17.4.5 of the JLS says that: > >> * An unlock on a monitor happens-before every subsequent lock on that >> monitor. >> * A write to a volatile field (§8.3.1.4) happens-before every subsequent >> read of that field. > > IOW, the situations (unlock-then-lock) and (volatile-write then > volatile-read) have the same visibility guarantees. > > Section 8.3.1.4 says: > >> A field may be declared volatile, in which case the Java memory model >> (§17) ensures that all threads see a consistent value for the variable. > > In your case, the thread calling done() is not seeing the same value as the > thread calling run(), which is not consistent. > > And for good measure Java Concurrency in Practice makes it much more > explicit (emphasis mine): > >> Volatile variables are not cached in registers or in caches where they are >> hidden from other processors, so *a read of a volatile variable always >> returns the most recent write by any thread*. > > And finally, on changing to an AtomicBoolean fixing the problem, JCIP says: > >> Atomic variables offer the same memory semantics as volatile variables > > So this doesn't really make sense either. > > All that's a long way of saying that the only ways I can see your situation > happening are: > > * pre-Java-1.5 (and hence pre-JSR-133) JVM > * JVM with a bug > * ordering is not as you expect, i.e. the actual chronological order is not: > > THREAD 1 THREAD 2 > spawn new thread > run() > done() > join() > > but rather: > > THREAD 1 THREAD 2 > spawn new thread > done() > run() > join() > > in which case the set of run to false at the start of run() overwrites the > set of it to true at the start of done(), and you're in for infinite loop > fun. > > Cheers, > > Paul >
