Revising the Java Thread Specification

OOPSLA workshop, Monday October 16th


This workshop was held as part of a continuing discussion of the Java Memory Model and Thread Specification. The original version of that specification is contained in (Chapter 17 of the Java Language Specification).

A consensus has formed that the existing Java Thread Specification is unacceptable and needs a complete replacement. Now, we are discussing the desired features for a revised specification and a way to formally specify them.

More information is available on the entire discussion and effort.

Slides and papers from workshop

WhatDiscussion leader
Memory Model TutorialSarita Adve
Issues for ProgrammersDoug Lea
Issues for JVM implementorsBill Pugh
Informal Semantics For ProgrammersBill Pugh
Cost of final fields on AlphaJeremy Manson
Hiding the Java Memory Model with CompilersJaejin Lee
Presentation and critique of CRF Model
(Slides/PPT) (Slides/PDF) (Slides/postscript) (OOPSLA paper /postscript)
Jan-Willem Maessen et al.
Presentation of Pugh's Model (Sides/pdf) (paper/pdf)Bill Pugh

Points and observations from the workshop

The following are some of the important points/issues that were discussed at the workshop

volatile memory accesses and lock/unlock operations must not be reordered

Joseph Bowbeer noted an apparent flaw in the Java-CRF paper. The paper allows volatile read/writes to be moved into a synchronized block (just as regular read/writes can be moved into a synchronized block). But that means that the following code would not work:

volatile boolean stop = false;

Thread 1:
synchronized(this) {
        while (!stop) work();

Thread 2: 
stop = true;
synchronized(this) {

Here, thread 2 is using the volatile flag stop to force thread 1 to exit the loop. If the write to stop in thread 2 is moved into the synchronized block, then the program deadlocks.

More to come

To be added as I get time...