Intel ITANIUM ARCHITECTURE - SOFTWARE DEVELOPERS VOLUME 3 REV 2.3, Руководство пользователя, Страница: 777 / 1898

Volume 2, Part 2: MP Coherence and Synchronization 2:529
indicates the value that
release
must have before the processor can leave the barrier.
The last processor to arrive at the barrier releases the other processors by setting
release
to the new
local_sense
value.
The
mf
instruction in Figure 2-5 is necessary only if the programmer wishes to ensure
that memory operations performed before the barrier code are visible to memory
operations performed by any processor after the barrier code.
2.4.3 Dekker’s Algorithm
Dekker’s algorithm [D65] is a common synchronization construct that arbitrates for a
resource through the use of several shared variables that indicate which processor is
using the resource. Each processor has its own flag variable that it shares with all other
processors in the system. When a processor attempts to enter the critical section, it
sets its flag to one and checks to make sure the flags for the other processors are all
zero.
The code in Figure 2-6 illustrates the core of this algorithm for a two-way
multiprocessor system. In this example, a processor makes a single attempt to acquire
the resource; typically, this code would appear in a loop. Although there is an array of
per-processor flag variables, the code uses
flag_me
and
flag_you
to indicate to the
flag variables for the processor attempting to obtain the resource and the other remote
processor, respectively.
Dekker’s algorithm assumes a sequential consistency ordering model. Specifically, it
assumes that loading zero from
flag_you
implies that a processor’s load and stores to
the flag variables occur before the other processor’s load and store to the flag variables.
If this is not the case, both processors can enter the critical section at the same time.
Using unordered loads or stores to access the
flag_me
and
flag_you
variables does not
guarantee correct behavior as the processor may re-order the accesses as it sees fit.
Using an acquire load and release store is also not sufficient to ensure correct behavior
because the ordering semantics always allow acquire loads to move earlier and release
stores to move later. In the absence of the
mf
, it is possible for the load from
flag_you
to occur before the store to
flag_me
; even with acquire and release operations.
The first
ld8
need not be an acquire load because of the control-flow that skips the
critical section: this load must become visible before any memory operations in the
critical section because the load must return data in order for the compare and branch
to resolve.