Skip to main content

Weekend Multithreaded Puzzler Fun!

Although I didn't go this year, one of my favorite parts of JavaOne is always Josh Bloch and Neal Gafter's talk on Java Puzzlers. (This year, Bill Pugh, my graduate advisor, stepped in for Neal.) A puzzler is a short snippet of code which has unexpected results, usually because some language or API feature behaves in a strange way. I enjoy them because I always think it is truly wonderful to have the depth of my ignorance exposed.

Josh and Neal wrote an excellent book with all of the Java Puzzlers through 2005, which is highly recommended, and occupies a place of honor in the stack of books in my bathroom.

The point of all of this is that occasionally, I will send Josh a multithreaded puzzler, and he will tell me it is no good, because you can't reproduce it every time. Here's one I sent him a couple of months ago.

It turns out that the following snippet of code displays the odd behavior 100% of the time under the JVM on my MacBook Pro (JDK 1.5.0_07), and won't display it at all on Linux. I haven't tried Windows. Can you figure out what the odd behavior will be? If you have an Intel-based Mac, you can probably even reproduce it.


class A {
  volatile static int x = 1;
  static {
      B.y = 1;
  }
}

class B {
  volatile static int y = 2;
  static {
      A.x = 2;
  }
}

public class Test {
  public static void main(String [] args) {
      Thread t1, t2;
      (t1 = new Thread() {
              public void run() {
                  A.x = 1;
              }
          }).start();
      (t2 = new Thread () {
              public void run() {
                  B.y = 2;
              }
          }).start();
      try {
          t1.join(); t2.join();
      } catch (InterruptedException e) {}
  }

}
Labels:

Comments

Danny said…
I have jdk 1.6/windows, so I ran this code with a grain of salt. I got A.x=1 & B.y=2 (by adding prints after the joins), which I assume is not the odd behavior.

I'm guessing the odd behavior is A.x=2 and B.y=1. (Am I completely off?) The only way I can imagine this happening is that:

1. the static variables are initialized.
2. The threads are run.
3. The static blocks are reordered such that they set the final values.

Maybe this was allowed by your compiler/jmm because it knew that setting B.y doesn't effect x (and setting A.x doesn't effect y), so it found a way to optimize by reordering the actions?
March 16, 2008 at 11:07 AM
Danny said…
Haha, you posted the answer. Ok, well I tried.
March 16, 2008 at 11:11 AM
Unknown said…
@Danny - I disagree with Danny here. I think reordering if atall it happens, will happens with respect to A.x or B.y but since both x and y are volatile, reordering should be taken care of. The only possible thing is the atomicity so in worst case the answer would either be A.x = 2 or B.y = 1.
October 1, 2010 at 3:40 AM
Post a Comment

Popular posts from this blog

Double Checked Locking

I still get a lot of questions about whether double-checked locking works in Java, and I should probably post something to clear it up. And I'll plug Josh Bloch's new book, too. Double Checked Locking is this idiom: // Broken -- Do Not Use! class Foo {   private Helper helper = null;   public Helper getHelper() {     if (helper == null) {       synchronized(this) {         if (helper == null) {           helper = new Helper();         }       }     }   return helper; } The point of this code is to avoid synchronization when the object has already been constructed. This code doesn't work in Java. The basic principle is that compiler transformations (this includes the JIT, which is the optimizer that the JVM uses) can change the code around so that the code in the Helper constructor occurs after the write to the helper variable. If it does this, then after the constructing thread writes to helper, but before it actually finishes constructing the object,
107 comments
Read more

What Volatile Means in Java

Today, I'm going to talk about what volatile means in Java. I've sort-of covered this in other posts, such as my posting on the ++ operator , my post on double-checked locking and the like, but I've never really addressed it directly. First, you have to understand a little something about the Java memory model. I've struggled a bit over the years to explain it briefly and well. As of today, the best way I can think of to describe it is if you imagine it this way: Each thread in Java takes place in a separate memory space (this is clearly untrue, so bear with me on this one). You need to use special mechanisms to guarantee that communication happens between these threads, as you would on a message passing system. Memory writes that happen in one thread can "leak through" and be seen by another thread, but this is by no means guaranteed. Without explicit communication, you can't guarantee which writes get seen by other threads, or even the order in whic
176 comments
Read more

Date-Race-Ful Lazy Initialization for Performance

I was asked a question about benign data races in Java this week, so I thought I would take the opportunity to discuss one of the (only) approved patterns for benign races. So, at the risk of encouraging bad behavior (don't use data races in your code!), I will discuss the canonical example of "benign races for performance improvement". Also, I'll put in another plug for Josh Bloch's new revision of Effective Java (lgt amazon) , which I continue to recommend. As a reminder, basically, a data race is when you have one (or more) writes, and potentially some reads; they are all to the same memory location; they can happen at the same time; and that there is nothing in the program to prevent it. This is different from a race condition , which is when you just don't know the order in which two actions are going to occur. I've put more discussion of what a data race actually is at the bottom of this post. A lot of people think that it is okay to have a data
53 comments
Read more