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

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

Volume 2, Part 2: MP Coherence and Synchronization 2:511
In the Itanium architecture, dependencies between operations by a processor have
implications for the ordering of those operations at that processor. The discussion in
Section 2.2.1.6 on page 2:515 and Section 2.2.1.7 on page 2:516 explores this issue in
greater depth.
The following sections examine the Itanium ordering model in detail. Section 2.2.1
presents several memory ordering executions to illustrate important behaviors of the
model.
Section 2.2.2 discusses how memory attributes and the ordering model
interact. Finally, Section 2.2.3 describes how the Itanium memory ordering model
compares with other memory ordering models.
2.2.1 Memory Ordering Executions
Multiprocessor software that uses shared memory to communicate between processes
often makes assumptions about the order in which other agents in the system will
observe memory accesses. As
Section 2.1.1 on page 2:507 describes, the Itanium
architecture provides a rich set of ordering semantics that allows software to express
different ordering constraints on a memory operation, such as a load. Writing correct
multiprocessor software requires that the programmer (or compiler) select the ordering
semantic appropriate to enforce the expected behavior.
For example, an algorithm that requires two store operations A and B become visible to
other processors in the order {A, B} will use stores with different ordering semantics
than an algorithm that does not require any particular ordering of A and B. Although it
is always safe to enforce stricter ordering constraints than an algorithm requires, doing
so may lead to lower performance. If the ordering of memory operations is not
important, software should use unordered ordering semantics whenever possible for
best possible performance.
This section presents multiprocessor executions to demonstrate the ordering behaviors
that the Itanium architecture allows and to contrast the Itanium ordering model with
other ordering models. The executions consist of sequences of memory accesses that
execute on two or more processors and highlight outcomes that the Itanium memory
ordering model either allows or disallows once all accesses on all processors complete.
A programmer can use these executions as a guide to determine which Itanium
memory ordering semantics are appropriate to ensure a particular visibility order of
memory accesses.
Section 2.2.1.1 presents the assumptions and notational conventions that the
upcoming discussions use to examine the executions. The remaining eleven sections
each explore a different facet of the Itanium ordering model:
• Relaxed ordering of unordered memory operations ( Section 2.2.1.2 ).
• Using acquire and release semantics to order operations ( Section 2.2.1.3 ).
• Loads may pass stores ( Section 2.2.1.4 ) and how to prevent this behavior
( Section 2.2.1.5 ).
• When dependencies do or do not establish memory ordering ( Section 2.2.1.6 and
Section 2.2.1.7 ).
• Satisfying loads from store buffers ( Section 2.2.1.8 ) and how to prevent this
behavior ( Section 2.2.1.9 ).
• Semaphore operations and local bypass ( Section 2.2.1.10 ).