Swing, SWT, and most (maybe all?) GUI APIs operate under some sort of thread confinement scheme. Most readers of this blog are probably somewhat familiar with the AWT/Swing event dispatch thread. Swing components are not thread-safe — they are thread-confined. This means when you call methods on Swing components, you must ensure you do so on the event dispatch thread. There are a handful of thread-safe exceptions to the rule, such as repaint().

During our last meeting it was brought to my attention that SWT adheres to a fail-fast policy. If you invoke SWT API methods from a foreign thread, an SWTException is thrown. Yes! This is the way to do it.

Swing, on the other hand, does not fail fast. Instead, if you execute Swing API methods outside the EDT, your app might work…or it might exhibit strange behaviour. You might notice painting artifacts, obscure exceptions, and possibly may encounter memory visibility issues on multi-processor systems.

Can We Fix Swing?

I suspect that most developers will agree a fail-fast approach works best. If your code has a bug, you may as well fail immediately with a specific exception (as SWT does), rather than live with subtle bugs (as Swing does) that are much harder to diagnose.

One approach involves changing every method in Swing as follows:

public void doSomething() {
  if (!SwingUtilities.isEventDispatchThread()) {
    throw new IllegalStateException(“…blah blah blah…”);
  }
  …normal code
}

Of course those three lines of code could be encapsulated into a helper-function of some sort, but the concept remains the same. This would require sweeping changes to Swing and is unlikely to happen. Throwing an exception, while arguably correct, does change the contract of these methods. Even if we do not like the current behavior, changing the semantics of nearly every Swing method may break quite a bit of code.

A More Serious Proposal

I believe annotations offer a more viable solution. Imagine if Java 7 Swing code added annotations to every Swing method that requires the EDT:

@RequiresEDT
public void doSomething() {
    …normal code
}

A new @RequiresEDT annotation would not change the behavior of any existing Swing API. It would, however, clearly document the intent of every Swing method. Furthermore, having that annotation in place (with runtime retention) makes it drop dead simple to use an AOP framework to enforce proper thread confinement. Or IDEs can more easily offer inspections that warn you of threading bugs.

Thoughts? Is this something we should pursue adding to Java 7?

Modern IDEs (IDEA, Eclipse) provide developers with lots of assistance when writing code. These IDEs mark code that is:

• just plain wrong (won’t compile)
• not used
• can be simplified
• and lots more

Can modern IDEs help developers find threading bugs? Let’s take a look at a specific example and find out.

public class Example {

    private boolean running = true;

    /**
     * Thread A starts counting
     */
    public void startCounting() {

        // Thread A keeps going until Thread B calls stop. Thread A may never stop!
        while (running) {
            countSomeSheep();
        }
    }

    /**
     * Thread B calls stop.
     */
    public void stop() {
        this.running = false;
    }

    /**
     * Executed by thread A.
     */
    private void countSomeSheep() {
        // zzz zzz zzz
    }
}

So what is wrong with the code? For a great explanation please review 3.1.4 Volatile variables in “Java Concurrency In Practice” book.

After reading that section you understand why the boolean variable named running should be marked volatile.

Let’s turn our attention to my favorite IDE for help tracking down this threading problem. IDEA (version 7, code named Selena) has an inspection named “While loop spins on field”. Here is the inspection’s description:

This inspection reports on any instances of while loops which spin on the value of a non-volatile field, waiting for it to be changed by another thread. In addition to being potentially extremely CPU intensive when little work is done inside the loop, such loops are likely have different semantics than intended, as the Java Memory Model allows such field accesses to be hoisted out of the loop, causing the loop to never complete even if another thread does change the field’s value.

Here is a snapshot of IDEA highlighting the threading problem:

Here is a snapshot of IDEA after making running volatile:

NOTE: IDEA 6.0.5 also has this inspection but it did not work!
NOTE: I have no idea if Eclipse has a similiar inspection.

Enjoy!

Nate touched on some of the features the newer versions of Java provide for concurrency at an OCI Java Lunch a couple of months earlier. Eric’s follow on Java Lunch concurrency topic nurtured the planted seed, but the BIG THANKS goes to Charles (I like calling him Charlie, with NO idea what he thinks) for sending out an email that provided the tipping point. I’m repeating facts (one of my patterns)… on to the show…

The screen shimmers and waves to a clear picture of six people sitting around a conference table. Some with books, others with laptops. Charles provides introductions and greetings, one attendee is even on the other side of a speaker phone working from home. The lunch time study group is REALLY on it’s way.

Chapter two of JCIP “Thread Safety” propones that the issue is about “managing access to state… shared mutable state”. If our programs don’t manage this correctly they are broke. That’s a capital period. The idea that’s trying to be communicated is that, what we used to believe about visibility of variables and objects, the order of execution of code, even the values that a variable has no longer is as simple as it was. Specifically when programs threads start running concurrently.

For me the moment of ‘Oh no, now what am I going to do’ came when it was pointed out the increment operation (i++) is not atomic, that it is a read, modify and write. The chapter went on to provide several insights into ways I need to think differently if I’m writing code for multiple thread access. Covering the topics of Atomicity, Locks, Guards, Liveness and Performance I was able to quickly grasp the authors’ definitions.

The book clearly shows me code that is broke and steers me to solutions on what I can do to make it correct. I am MOST grateful for the bits of humor, there is just not enough levity in this world. I enjoyed the discussion around the table and the time went by quickly. I was in a bit of a hurry, my tee time was quickly approaching. Slow fade…

Back on March 29, 2007, Charles Sharp sent this email to his fellow OCI/Advantage employees:

Greetings All,

Now that Eric has whetted your appetite for Java’s take on concurrency (or thrown you into a panic due to your understanding level), I thought this would be a good time to see if there is an interest in getting a  study group together to go through the book, Java Concurrency in Practice by Brian Goetz et al.

The study will be done in two parts.  The book has 16 chapters.  Part one of the study would cover chapters 2 through 9.  Part two would cover 10 through 16.  We’ll decide about Part two after we see how Part one goes.

Today I’m soliciting people to participate in Part one.

There will be eight meetings.  (The group might decide to have a pre-study organizational meeting to discuss and argue about format changes in the usual uninteresting fashion.)

Study meetings will be held during lunch hour (something like 11:30 to 12:30 with a half-hour overrun buffer to 1:00) once a week at the OCI office.

Due to other meetings through the week, I’m proposing either Monday, Wednesday, or Thursday as the meeting day.

The format of a meeting, as is always the case with a group of experienced wonks, is open for discussion.  Here’s a first pass to start that discussion.

Everyone reads the week’s chapter before the meeting.  (From my perspective, this is non-negotiable.  If you don’t have time to read a chapter a week, you just don’t have time to sign up for the study group.)

Each week one person will be assigned the chore of providing code that illustrates the concepts discussed in the week’s chapter.  I expect most of the attendees relate to code examples as well as anything.  So please note that part of what you’re signing up for is to provide this illustrative code for one of the meetings.

After the code presentation and attending discussion, I would like to leave time to do a quick “round the table” where each attendee has a chance to pitch in some point (or points) from the book that didn’t get covered.

And that’s pretty much the format plan.  In summary, we’re agreeing to meet once a week for eight weeks and do the homework.

If that sounds like your idea of fun, please stay away from me.

If that sounds like something that would be useful and constructive and a good leg up in understanding some crucial concepts, then give me a shout via reply email.

And thus, the study group was formed. We first met last week on Monday, April 16, and have met every Monday since then! Enjoy.