Wednesday, August 4, 2010

My article "Java Memory Model from a Programmer's Point-of-View" was published on DZone

You probably feel difficult to read Java Memory Model (JMM for short) from either Java Language Specification Third Edition (JLSv3 for short) or Java Virtual Machine Specification Second Edition (JVMSv2 for short) due to several reasons such as academic jargons and lack of basic understanding of modern microprocessors' out-of-order completion mechanism.
After all only JVM implementers must understand all of JLSv3 and JVMSv2.

So this article only teaches you the necessary parts of JMM that are needed for a programmer to make safe multi-threaded code. Here is the URL:

However I do have a question regarding the "Causality Loop" mentioned in the article and JMM: what microprocesses are supporting it?
I actually sent an email request to professor Sarita V. Adve because his paper "Memory Models: A Case for Rethinking Parallel Languages and Hardware" mentioned the same thing in Figure 4's case (a).

Here is my question:
My understanding is when core 1 speculatively executes "Y = 1", it puts the new value in a temporary store (core 2 will not see it) until it detects the predicate in the "if" statement becomes true; I have similar argument for core 2.  So neither core 1 nor core 2 will make its speculative write operation visible to the other core.

1 comment:

  1. Today I got a response from Profession Adve regarding the "Causality Loop". Here is the email:

    Dear Yong,

    There are no processors today that do this (otherwise, we would have trouble with the C++ and Java memory models prohibiting this). The goal here is to ensure (1) future processors never allow this outcome, and (2) to make it part of the formal semantics so programmers can rely on it. The data-race-free model clearly prohibits this outcome.