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

Page: 768 / 1898

2:520 Volume 2, Part 2: MP Coherence and Synchronization
Like Section 2.2.1.8 , the discussion in this section focuses on the outcome r1 = 1, r3 =
1, r2 = 0, and r4 = 0 because it is allowed if and only if store buffers can satisfy local
loads. The line of reasoning to show that the outcome r1 = 1, r3 = 1, r2 = 0, and r4 =
0 is not allowed in
Table 2-11 is similar to the reasoning used to show that this outcome
is allowed in the Table 2-10 execution from Section 2.2.1.8 on page 2:518 .
By the definition of the Itanium memory ordering semantics,
By allowing local and global visibility of operations M1 and M5 (similar to the discussion
in
Section 2.2.1.8 ), this assumption, along with the above constraints, together imply
that,
Consider these constraints on the Processor #0 operations m1, M1, M2, M3, and M4.
Making m1 visible before M2, M3, and M4 correctly honors the data dependency
through memory on Processor #0. However, unless it constrains the global visibility of
M1 to occur before M2, M3, and M4, Processor #0 violates the Itanium ordering
semantics. Specifically, the memory fence M2 must always be made visible after the
store M1. Allowing global and local visibilities of M1 in this case violates this constraint,
and thus, is not allowed. Essentially, by allowing M1 to become locally visible early, M3
would see M1 before the fence semantics for M2 were met (namely, that M1 be visible
before M2 and thus M3). Without local and global visibility of M1 and M5, the ordering
constraints are as this example originally postulated.
The code in Table 2-11 and these constraints together imply that
This contradicts the r1 = 1, r3 = 1, r2 = 0, and r4 = 0 outcome. The visibility of the
memory fence, M2, implies that all prior operations including the store to x, M1, are
globally visible. Thus, the load from x on Processor #1, M8, must observe the new
value of x and
but the outcome requires
2.2.1.10 Semaphores Do Not Locally Bypass
As Section 2.2.1.8 and Section 2.2.1.9 discuss, loads and acquire loads may be
satisfied with values placed in local store buffers (or other logically-equivalent
structures) by stores or release stores before the stored data becomes visible to other
agents in the coherence domain. The Itanium architecture explicitly prohibits such local
bypass either to or from semaphore operations. That is, semaphore operations cannot
be satisfied in this way nor can the data they store be used to satisfy loads or acquire
loads in this way.
The execution in Table 2-12 illustrates a variation on the execution in Table 2-10 where
the acquire loads have been replaced with exchange semaphore operations (which also
have acquire semantics).
M1 M2 M3 M4
  
M5 M6 M7 M8
  
m1 M1

m1

M2 M3 M4
  
m5 M5

m5

M6 M7 M8
  
r2 = 0 M4 M5 M1 M8 because M1 M4 and M4 M5 and M5 M8 r4 = 1
       
M1 M8

M8 M1.
