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.
| What | Discussion leader |
| Memory Model Tutorial | Sarita Adve |
| Issues for Programmers | Doug Lea |
| Issues for JVM implementors | Bill Pugh |
| Informal Semantics For Programmers | Bill Pugh |
| Cost of final fields on Alpha | Jeremy Manson |
| Hiding the Java Memory Model with Compilers | Jaejin 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 |
The following are some of the important points/issues that were discussed at the workshop
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:
Initially:
volatile boolean stop = false;
Thread 1:
synchronized(this) {
while (!stop) work();
}
Thread 2:
stop = true;
synchronized(this) {
consumeWork();
}
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.
To be added as I get time...