Intel ITANIUM ARCHITECTURE - SOFTWARE DEVELOPERS VOLUME 3 REV 2.3, Руководство пользователя

Страница: 775 / 1898

Volume 2, Part 2: MP Coherence and Synchronization 2:527
2.4.1 Spin Lock
Software commonly uses spin locks to guard access to a critical region of code. In these
locks, the software “spins” while waiting for a shared lock variable to indicate that the
critical region can be safely accessed. Typically, the lock code uses atomic operations
such as compare and exchange or fetch and add to update the shared lock variable.
Figure 2-4 shows a spin lock based on the
cmpxchg
instruction.
The spin lock code first initializes
ar.ccv
and a register with the values that indicate
that the lock is available and held, respectively. A compare and exchange obtains the
lock by exchanging
lock
with
1
if it currently holds
0
. Next, the first loop ensures that
the code spins in cache while the lock is held by someone else. Once this loop finds that
the lock is available, a compare and exchange instruction attempts to obtain the lock. If
this instruction fails (e.g. because someone else obtained the lock in the meantime),
the code resumes spinning in the first loop.
Spinning using only the
cmpxchg
/
cmp
/
br
loop may generate excessive coherency traffic.
For example, if the
cmpxchg
always stores to memory (even if the comparison fails) and
the lock is highly-contested, the platform may have to generate a number of read for
ownership transactions causing
lock
to move around the system. Using the first
ld8
/
cmp
/
br
loop avoids this problem by obtaining
lock
in a shared state. In the worst
case, when
lock
is not contested, this loop adds only the overhead of the additional
compare and branch.
The initial
ld8
need not be an acquire load because of the control-flow in the spin loop:
this load must become visible before the
cmpxchg8
because the load must return data
in order for the compare and branch to resolve. Further, the store that relinquishes the
lock after the critical section uses release semantics to prevent memory references
from the critical from moving after the reference that releases the lock. Finally, the
branches use “static predict not taken” hints to optimize for the case where the lock is
not highly contested.
Figure 2-4. Spin Lock Code
// available. If it is 1, another process is in the critical section.
//
spin_lock:
mov ar.ccv = 0 // cmpxchg looks for avail (0)
mov r2 = 1 // cmpxchg sets to held (1)
spin:
ld8 r1 = [lock] ;; // get lock in shared state
cmp.ne p1, p0 = r1, r2 // is lock held (ie, lock == 1)?
(p1) br.cond.spnt spin ;; // yes, continue spinning
cmpxchg8.acq r1 = [lock], r2, ar.ccv ;;// attempt to grab lock
cmp.ne p1, p0 = r1, r2 // was lock empty?
(p1) br.cond.spnt spin ;; // bummer, continue spinning
cs_begin:
// critical section code goes here...
cs_end:
st8.rel [lock] = r0 ;; // release the lock