developerWorks: Fixing the Java Memory Model, Part 1

“The Java platform has integrated threading and multiprocessing
into the language to a much greater degree than most previous
programming languages. The language’s support for
platform-independent concurrency and multithreading was ambitious
and pioneering, and, perhaps not surprisingly, the problem was a
bit harder than the Java architects originally thought. Underlying
much of the confusion surrounding synchronization and thread safety
are the non-intuitive subtleties of the Java Memory Model (JMM),
originally specified in Chapter 17 of the Java Language
Specification, and re-specified by JSR 133.

“For example, not all multiprocessor systems exhibit cache
coherency; if one processor has an updated value of a variable in
its cache, but one which has not yet been flushed to main memory,
other processors may not see that update. In the absence of cache
coherency, two different processors may see two different values
for the same location in memory. This may sound scary, but it is by
design–it is a means of obtaining higher performance and
scalability–but it places a burden on developers and compilers to
create code that accommodates these issues…”

Complete Story

Related Story:
Coders, Testers, Hackers, Packagers, Hardware for the InceptionOS
(Jul 16, 2002)

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends, & analysis