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

Page: 762 / 1898

2:514 Volume 2, Part 2: MP Coherence and Synchronization
The Itanium ordering semantics always allow a processor to make operations that
follow a release visible before the release and to make operations that precede an
acquire visible after the acquire.
Like the execution shown in Table 2-1 , the Itanium memory ordering model does not
place any constraints on the ordering of the operations on each processor in this
execution either.
Therefore, for reasons similar to those given in Section 2.2.1.2 for the execution shown
in Table 2-1 , the Itanium memory ordering model allows any outcome in this execution
as well. Further, the Itanium memory ordering model also allows all outcomes in similar
executions that differ only in the ordering semantics of the load and store operations
(e.g. those that replace M1 with an unordered store, etc.). There is no combination of
legal ordering semantics on these operations (recall that the Itanium instruction set
does not provide stores with acquire or fence semantics) that enforce either
or
2.2.1.5 Preventing Loads from Passing Stores to Different Locations
The only way to prevent the loads from moving ahead of the stores in the Table 2-3
execution is to separate them with a memory fence as the execution in Table 2-4
illustrates.
The Itanium memory ordering model only disallows the outcome r1 = 0 and r2 = 0 in
this execution. The memory fences on Processor #0 and Processor #1 (operations M2
and M5) force the load and store memory accesses to be made visible in program
order; no re-ordering is permitted across the fence. Thus, the following ordering
constraints must be met:
Given the code in Table 2-4 , these two constraints along with the assumption that the
outcome is r1 = 0 and r2 = 0 together imply that
Table 2-3. Loads May Pass Stores to Different Locations
Processor #0 Processor #1
st.rel [x] = 1 // M1
ld.acq r1 = [y] // M2
st.rel [y] = 1 // M3
ld.acq r2 = [x] // M4
Outcomes: all are allowed
Table 2-4. Loads May Not Pass Stores in the Presence of a Memory Fence
Processor #0 Processor #1
st [x] = 1 // M1
mf // M2
ld r1 = [y] // M3
st [y] = 1 // M4
mf // M5
ld r2 = [x] // M6
Outcome: only r1 = 0 and r2 = 0 is not allowed
M1 M2

M3 M4.

M1 M2 M3
 
M4 M5 M6
 
r1 = 0 M3 M4

M3 M6 because M4 M5 M6
    
r1= 0 M1 M3 because M1 M2 M3
   
M1 M3 and M3 M6 M1 M6 r2 = 1
    