The Java Memory Model gives some minimal guarantees about what happens if two threads are accessing the same variables. Brian Goetz describes this in chapter 7 of Java Concurrency in Practice. And here is a good summary of the new (1.5) Memory Model. Doug Lea describes the old memory model. If you really want to dig into it read some more formal specs.
The essence of the java memory models is: If one thread modifies a variable another thread may not see the change unless "some synchronization" happens (a synchronized block, a shared lock etc). But most real java VMs implement a much stricter memory model, that means if one thread modifies a variable the other thread sees it even without synchronization. And that is the problem. It is almost impossible to find those threading problems without a java VM that implements only the minimal memory model guarantees.
My favorite "theoretical threading bug" is NullProgressMonitor.cancelled should be volatile. If a java VM would implement only the minimal memory model the code would not work, but as John points out: "This is true in theory, but never happens in practice. In practice, the thread calling isCanceled may obtain a stale result for a short period of time, but the thread cache is soon synchronized. It is common practice to omit synchronization in cases where obtaining a stale value is acceptable.". This is unfortunately true. At least I could not construct an example where one thread would not see the changes made by another thread.
Getting threading right is extremely hard. Deadlocks often occur only if you have a bad day. You can get away with obviously wrong code just because Java VMs are so gracious.
I wonder if there is java VM that implements only the minimal memory model? It would be cool if it would be possible to force the VM to behave like the worst possible memory model. For example: it would not make changes visible to other threads unless the data is synchronized. This would be extremely helpful for testing and debugging purposes. I wonder how well eclipse would behave on such a "minimal memory model VM"....
I wonder, is it possible to implement on top of regular JVM with some kind of byte code instrumentation?
ReplyDeleteFor example, Terracotta (which extends Java Memory model to several JVMs) detects some cases when field are accessed without proper synchronization.
In my experience later Sun JVMs (and especially the server variants) are optimizing more aggressively. They don't have "the weakest possible memory model" because that isn't the aim. But they are exploiting the limits of the JMM more, which is why I'm turning on them if I want to examine a concurrency problem in a stress test.
ReplyDeleteJAX - it's all about Technology, Architecture, Agility
ReplyDeleteJAX is the the most comprehensive conference on web and enterprise development. It provides an ideal forum for software developers, project managers and architects to learn about the latest Technology, Architecture and Agile Methodologies. It is this very special blend of topics which has made JAX the conference of choice in Germany, India and Asia since its conception in 2001.
The master minds of our industry will be at JAX to share their knowledge, answer questions and facilitate discussions. The technical presentations and tutorials allow for deep coverage of the latest technologies and practical implementation techniques. Keynotes sessions presented by industry luminaries focus on how to deal with today's and tomorrow's challenges. Another significant vital benefit of JAX is the strong focus on networking and communication opportunities.
The primary goal of JAX is to showcase technical solutions for today’s problems and offer visions to the important trends of tomorrow. Delegates will benefit from hand-picked technical contents with no marketing bushwah.
http://www.jax-conf.com