Abstract 'The new Java Memory Model'
|
What's the worst thing that can happen when you fail to synchronize in a concurrent Java program? Its probably worse than you think – modern shared-memory processors can do some pretty weird things when left to their own devices.
Java was the first mainstream programming language to incorporate a formal, cross-platform memory model, which is what enabled the development of write-once, run-anywhere concurrent classes. It is the Java Memory model that defines the semantics of synchronized, volatile, and final.
However, because the most commonly used processors (Intel and Sparc) offer stronger memory models than is required by the JMM, many developers frequently use synchronization and volatile incorrectly, but have been insulated from failure by the stronger memory guarantees offered by the processor architecture they happen to be deploying on. (The infamous ?double checked locking? idiom is an example of this sort of error.) |
|
JDK 5.0 incorporates JSR-133, a revision of the Java Memory Model, which refines the semantics of synchronization, volatile variables, and final fields. Additionally, the new JMM provides a new safety guarantee ? initialization safety ? that allows immutable objects to be shared among threads without synchronization, if certain requirements are met. This talk describes the updated Java Memory Model for programmers who are familiar with the multithreading primitives in Java (synchronized and volatile.)
Understanding the Java Memory model is key to using the core concurrency primitives (synchronized and volatile) to develop thread-safe, efficient concurrent classes. We'll cover what a memory model is, what synchronization really means, and what can go wrong when you fail to use synchronization properly.
Date and Time
Audience
< Expert >
Speaker
Pictures
Slides
You must be logged in to see the slides
