[concurrency-interest] volatile guarantee for directbuffer

Boehm, Hans hans.boehm at hp.com
Wed Feb 15 15:04:37 EST 2012

> From: Holger Peine
> Sent: Tuesday, February 14, 2012 10:59 PM
> Cc: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] volatile guarantee for directbuffer
> Am 14.02.2012 20:46, schrieb Boehm, Hans:
> >> From: Holger Peine
> [Earlier discussion was correctly resolved.]

> 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.
Definitely.  But on x86 the required ordering with respect to non-volatile operations is already ensured by the TSO memory model for ordinary loads and stores, at least if the compiler does nothing to violate it.  Earlier memory operations can't be reordered with respect to a store, and later operations can't be reordered with respect to a load.  That's actually enough to make your original example work.

Even on architectures where this is not automatically ensured, you'd need a fence BEFORE a volatile store, not after, to enforce the ordering required for your example.

The fence AFTER a volatile store is there to make things like the Dekker's example work: (v, w both volatile, initially zero, r1 and r2 are local)

Thread 1:
x = 1;
r1 = y;

Thread 2:
y = 1;
r2 = x;

Volatiles guarantee sequential consistency, so r1 = r2 = 0 must be impossible.  But on x86, a store followed by a load can effectively be reordered.  So you need a fence.

There is an argument that the hardware-software interface here could stand improvement, since the fences following volatile stores rarely actually order anything important, but do severely constrain the hardware in preventing reordering that doesn't matter.  And some architectures are beginning to redesign this interface.


> - At least that's how I understand the JMM. I'd be eager to hear that
> I've been wrong all the time.
> Regards,
> 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
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list