Intel ITANIUM ARCHITECTURE - SOFTWARE DEVELOPERS VOLUME 3 REV 2.3, Manual

Page: 771 / 1898

Volume 2, Part 2: MP Coherence and Synchronization 2:523
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 Section 2.2.1.11 , the Itanium memory ordering model requires that release
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.
Table 2-1 illustrates this
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.
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
at Processor #1. Because M2 is an acquire load and ,
, where m3 represents the local visibility of memory operation 1 (see
Section 2.2.1.8 ). Thus, . Since M1 is a release store, it appears to become
visible to all processors at the same time. This fact and together imply
.
If r2 = 1, . Because M4 is an acquire load, . If r3 = 0, then .
Together, these imply , which contradicts the observation from the previous
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.
Table 2-15. Intel
®
Itanium
®
Architecture Obeys Causality
Processor #0 Processor #1 Processor #2
st.rel [x] = 1 // M1 ld.acq r1 = [x]// M2
st
[y] = 1 // M3
ld.acq r2 = [y] // M4
ld r3 = [x] // M5
Outcome: only r1 = 1, r2 = 1, and r3 = 0 is not allowed
M1 M2

M2 M3 »
M2 m3

M1 m3

m3 M3

M1 M3

M3 M4

M4 M5

M5 M1

M3 M1
