[concurrency-interest] volatile guarantee for directbuffer

Holger Peine Holger.Peine at fh-hannover.de
Wed Feb 15 01:59:01 EST 2012

Am 14.02.2012 20:46, schrieb Boehm, Hans:
>> From: Holger Peine
>> (I use to tell my students "writing to a volatile flushes the cache".)
> That somewhat conveys the right idea, but not entirely.  In particular:
> - If only v is volatile, then x = 1; v = 1; z = 1 does not ensure that the write to x becomes visible before the write to z.  

The JMM does ensure that the write to x becomes visible together with
the write to v, and that was the original poster's (Talip Ozturk)

What happens to z is another question: The JMM only guarantees that it
will not become visible before the write to x or v (since it
happens-after the x and v writes). It may never become visible at all.
It it becomes visible, however, then that will be after (or at the same
time as) the writes to x and v (since any other ordering would violate
the happens-before relation). So your above statement about z is
technically correct (since it may never become visible at all), but
somewhat misleading (since it cannot be become visible before x and v).

Your later statement that "the fence after a volatile
store ... It's there only to order the volatile
store with respect to a possible subsequent volatile load."
sounds like what was true in Java prior to Java 5. Since Java 5,
however, volatile stores do impose an ordering not only regarding
other volatile accesses, but also regarding non-volatile accesses
that happened-before the volatile store.

- At least that's how I understand the JMM. I'd be eager to hear that
I've been wrong all the time.

Holger Peine

Prof. Dr. Holger Peine
Hochschule Hannover, Fakultät IV, Abt. Informatik
Tel: +49(511)9296-1830  Fax: -1810 (shared, please state my name)
Ricklinger Stadtweg 120, D-30459 Hannover, Germany

More information about the Concurrency-interest mailing list