The Silently Shifting Semicolon

We always strive for performance, meaning that the compiler will apply tons of modifications to your code to make it fast. These can really get in the way of correctness, or at least of what your think should happen. We’ve seen an example of this in the context of standard concurrency (the double-checked locking problem) and of lockfree programming (the ABA bug).

The Silently Shifting Semicolon is a research article whose introduction section has a great description of certain issues with correctness and performance. The article is authored by D. Marino, T. Millstein, M. Musuvathi, S. Narayanasamy, and A. Singh, and was published in the 1st Summit on Advances in Programming Languages, SNAPL 2015, May 3-6, 2015, Asilomar, California, USA

The introduction proceeds as a conversation between a CS student and a CS professor. Below I quote/paraphrase/explain some of the main points of the introduction section of The Silently Shifting Semicolon. It should be understood that every statement below references that article and is not my own. The writing in the article is great and very entertaining, and my summarizing of it below does not do it justice. I highly recommend you read the original, but in class we will go through my summary only.

Off to a good start

Alice is a bright and enthusiastic freshman in a programming languages (PL) course and has learned that “Modern programming languages enforce simple yet powerful abstractions that hide the complexities of the machine and make programming easier and safer”. One of the fundamental concepts is sequential composition:

 A ; B     // semicolon means "do A and then do B"

Soon after, Alice learns the parallel composition concept:

 A ; B || C     // Do "A followed by B" and in parallel "C"

In the above, C can be done at any time, but B must follow A.

Alice writes her first parallel program in Java:

A: Pasta p = new Pasta();  B: cooked=true;    ||    C: if (cooked)  p.drain();

The problem is that once in a while, Alice’s program throws a null-pointer exception!!

Alice is baffled and talks to her professor:

Like Alice at this point you should really feel that your entire world has collapsed and that you can no longer write code!

At this point Alice needs to think for a while and then:

It turns out that since Java 5, accesses to a volatile variable CANNOT be reordered by the JVM. Therefore, another use of volatile is to guarantee the happens-before relationship (see the “Java Threads, Synchronization” module!).

The moral of the story is that “achieving sane semantics in Java requires programmers to meticulously avoid data races with little language support for doing so.”
The Silently Shifting Semicolon article then proposes that “programming languages should guarantee sequential composition, and it should not be possible for programs to expose the effects of compiler and hardware reorderings.” If this were the case, then Alice would never have quit the major :)