Writing concurrent code is hard to begin with; the language should not make it any harder. While the Java platform included support for threading from the outset, including a cross-platform memory model that was intended to provide \"Write Once, Run Anywh
Tutorial Details:
Visibility, revisited
One of the key concepts needed to understand the JMM is that of visibility -- how do you know that if thread A executes someVariable = 3, other threads will see the value 3 written there by thread A? A number of reasons exist for why another thread might not immediately see the value 3 for someVariable: it could be because the compiler has reordered instructions in order to execute more efficiently, or that someVariable was cached in a register, or that its value was written to the cache on the writing processor but not yet flushed to main memory, or that there is an old (or stale) value in the reading processor\'s cache. It is the memory model that determines when a thread can reliably \"see\" writes to variables made by other threads. In particular, the memory model defines semantics for volatile, synchronized, and final that make guarantees of visibility of memory operations across threads.
When a thread exits a synchronized block as part of releasing the associated monitor, the JMM requires that the local processor cache be flushed to main memory. (Actually, the memory model does not talk about caches -- it talks about an abstraction, local memory, which encompasses caches, registers, and other hardware and compiler optimizations.) Similarly, as part of acquiring the monitor when entering a synchronized block, local caches are invalidated so that subsequent reads will go directly to main memory and not the local cache. This process guarantees that when a variable is written by one thread during a synchronized block protected by a given monitor and read by another thread during a synchronized block protected by the same monitor, the write to the variable will be visible by the reading thread. The JMM does not make this guarantee in the absence of synchronization -- which is why synchronization (or its younger sibling, volatile) must be used whenever multiple threads are accessing the same variables.
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Fixing the Java Memory Model, Part 2
View Tutorial: Fixing the Java Memory Model, Part 2
Related
Tutorials:
 Understanding Java Card 2.0 - JavaWorld March 1998
Understanding Java Card 2.0 - JavaWorld March 1998
|
Programming XML in Java, Part 3 - JavaWorld July
2000
Programming XML in Java, Part 3 - JavaWorld July
2000
|
Easy Java/XML integration with
JDOM, Part 1 - JavaWorld May 2000
Easy Java/XML integration with
JDOM, Part 1 - JavaWorld May 2000
|
Alternative deployment
methods, Part 3: The code - JavaWorld September
2000
Alternative deployment
methods, Part 3: The code - JavaWorld September
2000
|
Mapping XML to Java, Part 1 - JavaWorld August 2000
Mapping XML to Java, Part 1 - JavaWorld August 2000
|
Mapping XML to Java, Part 2 - JavaWorld October
2000
Mapping XML to Java, Part 2 - JavaWorld October
2000
|
Printing in
Java, Part 1 - JavaWorld October 2000
Printing in
Java, Part 1 - JavaWorld October 2000
|
Warning! Threading in
a multiprocessor world - JavaWorld February 2001
Warning! Threading in
a multiprocessor world - JavaWorld February 2001
|
Can double-checked locking be fixed? - JavaWorld May 2001
Can double-checked locking be fixed? - JavaWorld May 2001
|
Java security evolution
and concepts, Part 2
Java security evolution
and concepts, Part 2
|
Boost Struts with
Boost Struts with XSLT and XML
|
Java scripting languages: Which is
right for you?
Java scripting languages: Which is
right for you?
|
Rumble in the
jungle: J2EE versus .Net, Part
1
Rumble in the
jungle: J2EE versus .Net, Part
1
|
Business process
automation
made easy with
Java, Part 1
Business process
automation
made easy with
Java, Part 1
|
Business process
automation
made easy with
Java, Part 2
Business process
automation
made easy with
Java, Part 2
|
Fixing the Java Memory Model, Part 2
Writing concurrent code is hard to begin with; the language should not make it any harder. While the Java platform included support for threading from the outset, including a cross-platform memory model that was intended to provide \"Write Once, Run Anywh
|
Fixing the Java Memory Model, Part 1
JSR 133, which has been active for nearly three years, has recently issued its public recommendation on what to do about the Java Memory Model (JMM).
|
Template-Based Code Generation with Apache Velocity, Part 2
Template-Based Code Generation with Apache Velocity, Part 2
As described in part one of this series, code generation typically uses a template engine to transform some kind of "model" into compilable code, given the formatting specified by a template.
|
Taming Tiger
Taming Tiger, Part 2
Understanding generics
Welcome to the second part of this three-part series on Sun Microsystems' latest release of the Java 2 Platform, Standard Edition (J2SE). To refresh your memory, Part 1 was a quick introduction to J2SE 1.5
|
JDBC scripting, Part 2
JDBC scripting, Part 2
Programming and Java scripting in JudoScript
Summary
JudoScript is a rich functional scripting language, and an easy and powerful general programming and Java scripting language.
JudoScript's power comes from its synergy of
|
|
|
|
