Intel ITANIUM ARCHITECTURE - SOFTWARE DEVELOPERS MANUAL VOLUME 1 REV 2.3 Manual page 771

The Itanium memory ordering model also allows this outcome if the release stores M1
and M4 are replaced with a memory fence followed by an unordered store. From the
standpoint of a single processor, a release store has equivalent ordering semantics on
the local processor to a memory fence followed by an unordered store. However,
because the store in the memory fence/unordered store pair is unordered, it does not
have any ordering requirements with respect to a remote processor. Even when
processors are allowed to construct different interleavings, the ordering of an individual
processor's memory references within the interleaving must always respect the
ordering constraints placed on those references.
2.2.1.12 Obeying Causality
As noted in
stores and semaphore operations (both acquire and release forms) become visible to all
observers in the coherence domain in a single total order with the exception that each
processor may observe (via loads or acquire loads) its own update early. Thus, each
observer in the coherence domain sees the same interleaving of release stores, and
semaphores operations from the other processors in the coherence domain.
A consequence of this is the fact that the Itanium memory ordering model respects
causality in a certain way. Specifically, if a release store or semaphore operation
causally precedes any store or semaphore operation, then the two operations will
become visible to all processors in the causality order.
behavior. Suppose that M2 reads the value written by M1. In this case, there is a causal
relationship from M1 to M3 (a control dependency could also establish such a
relationship). The fact that the store to x is a release store implies that, since there is a
causal relationship from M1 to M3, M1 must become visible to processor #2 before M3.
Table 2-15.
st.rel [x] = 1 // M1
The Itanium memory ordering model disallows the outcome r1 = 1, r2 = 1, and r3 = 0
in this execution (all other outcomes are allowed). To see this, we note the following. If
r1 = 1, then

M2 m3
Section 2.2.1.8). Thus,
visible to all processors at the same time. This fact and

M1 M3
If r2 = 1,
Together, these imply
paragraph. Thus, the outcome r1 = 1, r2 = 1, and r3 = 0 is disallowed.
The indicated outcome would also be disallowed if M1 were a semaphore operation
because, like release stores, each semaphore must appear to become visible at all
processors at the same time. The indicated outcome would be allowed if M1 were a
weak store, as a weak store may appear to become visible at different times to
different processors.
Volume 2, Part 2: MP Coherence and Synchronization
Section 2.2.1.11, the Itanium memory ordering model requires that release
®
Intel Itanium
Processor #0
ld.acq r1 = [x]// M2
st
Outcome: only r1 = 1, r2 = 1, and r3 = 0 is not allowed
 at Processor #1. Because M2 is an acquire load and
M1 M2
, where m3 represents the local visibility of memory operation 1 (see

M1 m3
.
 . Because M4 is an acquire load,
M3 M4
 , which contradicts the observation from the previous
M3 M1
Table 2-1
®
Architecture Obeys Causality
Processor #1
[y] = 1 // M3
. Since M1 is a release store, it appears to become
M4
illustrates this
Processor #2
ld.acq r2 = [y]
ld r3 = [x]
M2 M3
 together imply
m3 M3
 . If r3 = 0, then
M5 M5
// M4
// M5
,
»
 .
M1
2:523