Intel ITANIUM ARCHITECTURE - SOFTWARE DEVELOPERS MANUAL VOLUME 1 REV 2.3 Manual page 759

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
greater depth.
The following sections examine the Itanium ordering model in detail.
presents several memory ordering executions to illustrate important behaviors of the
model. Section 2.2.2
interact. Finally,
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
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
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
• Using acquire and release semantics to order operations
• Loads may pass stores
(Section
• When dependencies do or do not establish memory ordering
Section
• Satisfying loads from store buffers
behavior
• Semaphore operations and local bypass
Volume 2, Part 2: MP Coherence and Synchronization
on page 2:515 and
discusses how memory attributes and the ordering model
Section 2.2.3 describes how the Itanium memory ordering model
Section 2.1.1
presents the assumptions and notational conventions that the
(Section
2.2.1.5).
2.2.1.7).
(Section 2.2.1.9).
Section 2.2.1.7 on page 2:516
on page 2:507
(Section
2.2.1.4) and how to prevent this behavior
(Section 2.2.1.8) and how to prevent this
(Section 2.2.1.10).
explores this issue in
Section 2.2.1
describes, the Itanium
2.2.1.2).
(Section 2.2.1.3).
(Section 2.2.1.6 and
2:511