JavaMemoryModel: Write atomicity for volatiles

From: Sarita Adve (
Date: Wed Jul 18 2001 - 14:42:34 EDT

> -----Original Message-----
> From: Boehm, Hans []
> Sent: Wednesday, July 11, 2001 5:23 PM

> 2) If two threads write two different volatile locations, and if there are
> several observer threads, do all the observer threads see the
> writes in the
> same order? To what extent is there a global total order among all the
> volatile accesses?

Ok, I classify this issue as write atomicity. In other words, when a write
becomes visible to a processor, does it become visible to all processors at
the same time? There are at least three options:

(1) Yes, a write becomes visible to all processors at the same time.
(2) A write can become visible to its own processor early, but becomes
visible to all other processors at the same time.
(3) A write can become visible to some other processors early.

I believe your question is about whether we should permit option 3.

TSO, RMO, and Alpha do not permit option 3 for any writes.

The IA-64 model does not seem to permit option 3 for release and semaphore
writes (I am tentative because their wording isn't formal, but all their
examples show that it does not permit it). IA-64 does allow option (3) for
other (non-release, non-semaphore) writes. For these "normal" writes, in my
understanding, there is no general way to use a fence to ensure that the
writes appear atomic.

The PowerPC model permits option 3 for all writes. The SYNC instruction
could be used to get atomicity, but the original specification had some
ambiguities about this and I am not sure if a correction was published.

As far as real machines - The last time I did a survey of this issue (with
Kourosh about five years ago), the only real machine that permitted option
(3) was the Cray T3D.

As far as option (2), it enables reading early from a processor's own write
buffer. Many systems allow this, including Alpha, SPARC, and Intel. However,
it turns out that this is not detectable with Alpha and PowerPC models (and
for that matter with SC).

Option (2) is related to local data dependences and program order related
memory model constraints. If we go with requiring that program ordered
volatile write followed by volatile read should be usable for ordering, then
option (2) is prohibited directly. If we want to go with more of TSO like
semantics for program ordering of volatile write --> volatile read, then we
would need to debate this issue.

My opinion: requiring non-normal writes to be atomic (i.e., prohibit options
2 and 3) should be acceptable from hardware point of view.

But of course, I am not in favor of putting this in the spec or writing the
spec so this can be derived as a general property of all non-normal writes.

I hope this helps.


JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:33 EDT