[concurrency-interest] volatile guarantee for directbuffer

Holger Peine Holger.Peine at fh-hannover.de
Thu Feb 16 02:35:55 EST 2012


Am 15.02.2012 21:04, schrieb Boehm, Hans:
> 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.

Agreed - discussion resolved, I think.

> 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.

Interesting point (and news to me), but taking us too far here, I think.

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


More information about the Concurrency-interest mailing list