Re: boolean and thread safety

From:

markspace <nospam@nowhere.com>

Newsgroups:

comp.lang.java.programmer

Date:

Sun, 13 Feb 2011 16:42:45 -0800

Message-ID:

<ij9tqa$lkl$1@news.eternal-september.org>

On 2/13/2011 3:17 PM, Volker Borchert wrote:

Lew wrote:

They already have. The changes to the Java memory model with version 3 of the
JLS were a direct response to the increased visibility of concurrency bugs,
most of which had been in production for a while before anyone noticed.

Is there a concise description of _what_ was considered "broken" in the
older memory model, and why, and how it was fixed?

I may be wrong here, but I believe what was broken was there wasn't a
formal memory model. The informal memory model of "just try to compile
this" was so loose it had basically no useful semantics.

Consider our old pal the infamous double checked locking.

class Foo {
     private Helper helper = null;
     public Helper getHelper() {
         if (helper == null) {
             synchronized(this) {
                 if (helper == null) {
                     helper = new Helper();
                 }
             }
         }
         return helper;
     }
  }

This does in fact work on i86 about 99% of the time, even though it's
broken because based on random events it won't work some of the time.
However on other CPU architectures (like Alpha) it doesn't work, at all.
  Like not even once.

So Java had to implement a memory model so everyone was on the same page
and knew how to implement basic things like how two threads execute
together.