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

Volume 2, Part 2: MP Coherence and Synchronization 2:535
This code fragment changes the instruction at the address
code
to the new instruction
new_inst
. After executing this code, the change is visible to the local and remote
processor’s caches and to the local processor’s pipeline, but may not be visible to
remote processor’s pipelines.
The sequence in Figure 2-10 is similar to the code from Figure 2-8 except an
mf
instruction occurs between the
sync.i
and
srlz.i
instructions. The fence is necessary
if software must ensure that the code image update is made visible to all remote
processors before any subsequent memory operations from the local processor.
Although the
sync.i
, which orders the
st
/
fc.i
pair, has unordered semantics, it is an
orderable operation and thus obeys the release or fence semantics of subsequent
instructions (unlike an
fc.i
instruction; see Section 4.4.7, “Sequentiality Attribute and
Ordering” for more information).
Because the pipeline is not snooped, the code in Figure 2-10 cannot ensure that a
remote processor’s pipeline is coherent with the code image update. In the local case
shown in
Figure 2-8 , the
srlz.i
instruction enforces this coherency. As a result, the
remote processor must serialize its instruction stream before it executes the updated
code in order to ensure that a stale copy of some of the updated code is not present in
the pipeline. This can be accomplished by explicitly executing a
srlz.i
before
executing the updated code or by forcing an event that re-initiates any code fetches
performed after the
fc.i
is observed to occur, such as an interruption or
rfi
.
Several optimizations to this code are possible depending on how software uses the
updated code. Specifically, the
mf
and
srlz.i
can be eliminated under certain
circumstances.
The
srlz.i
is not necessary if the local processor that updates the code image does not
ever execute the new code. In this case, the local processor does not require its
pipeline to be coherent with the changes to the code image. The fence is not necessary
if the code image update can be made visible to remote processors in any relationship
with subsequent memory operations from the local processor.
Figure 2-10. Updating a Code Image on a Remote Processor
patch_l_and_r:
st [code] = new_inst // write new instruction
fc.i code ;; // flush new instruction
sync.i ;; // sync i stream with store
// If the local processor must ensure that remote processors see
// the preceding memory updates before any subsequent memory
// operations, the following code is also necessary.
//
mf ;; // make store visible to others
// If the local processor is going to execute the code and cannot
// cannot ensure instruction stream serialization, the following
// code is also necessary,
//
srlz.i ;; // serialize my pipeline
// Local caches and pipeline are now coherent with new_inst, remote
// caches are now coherent with new_inst...