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

Because all of the operations in
model does not place any constraints on the order in which a processor based on the
Itanium architecture makes the operations visible.
Observing a particular value in r2, for example, does not allow any inferences to be
made about the value of r1 because the pair of stores on Processor #0 may become
visible in any order. Therefore, all outcomes are possible as the system may interleave
M1, M2, M3, and M4 in any order without violating the memory ordering constraints.
2.2.1.3 Enforcing Basic Ordering
Using acquire and release ordering semantics enforces an ordering between both the
Processor #0 operations M1 and M2 and the Processor #1 operations M3 and M4 from
the Table 2-1
Table 2-2.
st
st.rel
The Itanium ordering model only disallows the outcome r1 = 1 and r2 = 0 in this
execution. The release semantics on M2 and acquire semantics on M3 affect the
following ordering constraints:
Given the code in
that the outcome is r1 = 1 and r2 = 0 together imply that:
This contradicts the postulated outcome r1 = 1 and r2 = 0 and thus the Itanium
ordering model disallows the r1 = 1 and r2 = 0 outcome.
In operational terms, if Processor #1 observes M2, the release store to y (i.e. r1 is 1), it
must have also observed M1, the unordered store to x (i.e. r2 is 1 as well), given the
ordering constraints. Therefore, the Itanium ordering model must disallow the outcome
r1 = 1 and r2 = 0 in this execution as this outcome violates these constraints.
Stronger ordering models that do not relax load-to-load and store-to-store ordering,
such as sequential consistency, impose these same ordering constraints on M1, M2, M3,
and M4 and therefore also do not allow the outcome r1 = 1 and r2 = 0.
2.2.1.4 Allow Loads to Pass Stores to Different Locations
The Itanium memory ordering model allows loads to pass stores as shown in the
execution sequence in
allowing the processor to complete loads that follow a store that misses the cache.
Volume 2, Part 2: MP Coherence and Synchronization
Table 2-1
execution as shown in
Acquire and Release Semantics Order Intel
Operations
Processor #0
[x] = 1 // M1
[y] = 1 // M2
Outcome: only r1 = 1 and r2 = 0 is not allowed
Table 2-2, these two ordering constraints along with the assumption
  
r1 = 1 M2 M3 M1
Table 2-3. Permitting this behavior can improve performance by
are unordered, the Itanium memory ordering
Table 2-1.
ld.acq r1 = [y]
ld r2 = [x]

M1 M2

M3 M4
 
M4 (because M1 M2 and M3
® ®
Itanium Memory
Processor #1
// M3
// M4
 
M4) r2 = 1
2:513