volatile, acquire/release, memory fences, and VC2005

re: volatile, acquire/release, memory fences, and VC2005

Peter Ritchie — Sun, 22 Jul 2007 00:03:06 GMT

http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=288218 seems to suggest that ld.acq/st.rel aren't always generated.

re: volatile, acquire/release, memory fences, and VC2005

lbargaoanu — Tue, 24 Jul 2007 19:06:20 GMT

Typo :)

"must remain about Store V" is

"must remain above Store V"

re: volatile, acquire/release, memory fences, and VC2005

kanggatl — Fri, 03 Aug 2007 02:02:46 GMT

Peter, you're right. On Itanium there is a bug...

re: volatile, acquire/release, memory fences, and VC2005

JAG — Wed, 08 Aug 2007 19:35:28 GMT

From the original post "But Loads with respect to other Loads will remain ordered." - I don't see how to resolve this assertion with Intel 3a 7.2.2 "Memory Ordering in P6 and More Recent Processor Families" which states "1. Reads can be carried out speculatively and in any order."

re: volatile, acquire/release, memory fences, and VC2005

kanggatl — Thu, 09 Aug 2007 19:11:54 GMT

JAG, that's a good question. You can think of it this way: if you were following the traffic of memory reads you may see the read (for example for validation of the hardware), but read reordering should not be made apparent to the programmer.

re: volatile, acquire/release, memory fences, and VC2005

JAG — Thu, 09 Aug 2007 23:32:01 GMT

Mmm, this seems to imply that Intel’s Rule 1 (cited above) is referring to load operations as they might appear on the bus, and not to actual instructions (and their dependents). That these can be done out-of-order, but always appear to the program in-order, seems to imply an implicit attachment to any other program/CPU which might be storing. Possibly this is attached to the cache coherence mechanism? That is, assuming “speculative” refers to any instruction beyond the one at “current EIP” then it would mean that none of these instructions are committed (retired) until they are the target of the “current EIP” AND no intervening cache invalidate has arrived. Presumably if a invalidate arrives then the speculated instruction (and its dependents) would be discarded/re-executed. As in (putting aside compiler actions for the moment):

CPU0 CPU1

a=0; ...

b=0; ...

... ...

a=1; while (b!=2);

b=2; c=a;

... e=c+1;

CPU1 could speculatively process c=a, and possibly e-c+1 (etc), but could not retire c=a (etc) until it became the target of “current EIP”. Assume this speculation observes a==0. At a later time, CPU1 observes b==2. Because stores are ordered, this will always have been preceded by CPU0 making an exclusive fetch for the line containing a, which will be observed as an “invalidate” by CPU1, which would discard the observation a==0.

Is this the kind of play that allows loads to be unordered and ordered at the same time??

re: volatile, acquire/release, memory fences, and VC2005

kanggatl — Thu, 16 Aug 2007 18:02:44 GMT

Jag, it looks something like that. There is something by Frey that describes the general algorithm that is often cited. For specific details though, you'd need to contact each hardware vendor.

re: volatile, acquire/release, memory fences, and VC2005

JAG — Sat, 25 Aug 2007 02:09:36 GMT

Okay, thanks. I found some words from Andy Glew on the topic, reinforcing your comments.

http://groups.google.com/group/comp.arch/browse_frm/thread/64bc52823607b2c0/e120cb283153d58a?lnk=st&q=load+order+x86+fence+glew&rnum=3&hl=en#e120cb283153d58a

I've another related question, this one about the xxxBarrier intrinsics (as in 7.1). The way I read it (which could be whacky of course), given

load a

__ReadBarrier

load b

the "load a" is not permitted to be moved below the barrier, but there are no constraints on moving the "load b" above the barrier. Similarly, given

store a

__WriteBarrier

store b

the "store a" may not move below the barrier, but the "store b" is not constrained.

This seems odd to me (eg, it doesn't match acquire/release semantics), so I'm guessing I'm misreading somewhere...

TIA

JAG