Vol. 3A 8-5

MULTIPLE-PROCESSOR MANAGEMENT

Self-modifying code will execute at a lower level of performance than non-self-modifying or normal code. The 
degree of the performance deterioration will depend upon the frequency of modification and specific characteristics 
of the code.
The act of one processor writing data into the currently executing code segment of a second processor with the 
intent of having the second processor execute that data as code is called cross-modifying code. As with self-
modifying code, IA-32 processors exhibit model-specific behavior when executing cross-modifying code, 
depending upon how far ahead of the executing processors current execution pointer the code has been modified. 
To write cross-modifying code and ensure that it is compliant with current and future versions of the IA-32 archi-
tecture, the following processor synchronization algorithm must be implemented:

(* Action of Modifying Processor *)
Memory_Flag ← 0; (* Set Memory_Flag to value other than 1 *)

Store modified code (as data) into code segment;
Memory_Flag ← 1;

(* Action of Executing Processor *)
WHILE (Memory_Flag ≠ 1)

Wait for code to update;

ELIHW;

Execute serializing instruction; (* For example, CPUID instruction *)
Begin executing modified code;

(The use of this option is not required for programs intended to run on the Intel486 processor, but is recommended 
to ensure compatibility with the Pentium 4, Intel Xeon, P6 family, and Pentium processors.)
Like self-modifying code, cross-modifying code will execute at a lower level of performance than non-cross-modi-
fying (normal) code, depending upon the frequency of modification and specific characteristics of the code.
The restrictions on self-modifying code and cross-modifying code also apply to the Intel 64 architecture.

8.1.4 

Effects of a LOCK Operation on Internal Processor Caches

For the Intel486 and Pentium processors, the LOCK# signal is always asserted on the bus during a LOCK operation, 
even if the area of memory being locked is cached in the processor.
For the P6 and more recent processor families, if the area of memory being locked during a LOCK operation is 
cached in the processor that is performing the LOCK operation as write-back memory and is completely contained 
in a cache line, the processor may not assert the LOCK# signal on the bus. Instead, it will modify the memory loca-
tion internally and allow it’s cache coherency mechanism to ensure that the operation is carried out atomically. This 
operation is called “cache locking.” The cache coherency mechanism automatically prevents two or more proces-
sors that have cached the same area of memory from simultaneously modifying data in that area.

8.2 MEMORY 

ORDERING

The term memory ordering refers to the order in which the processor issues reads (loads) and writes (stores) 
through the system bus to system memory. The Intel 64 and IA-32 architectures support several memory-ordering 
models depending on the implementation of the architecture. For example, the Intel386 processor enforces 
program ordering (generally referred to as strong ordering), where reads and writes are issued on the system 
bus in the order they occur in the instruction stream under all circumstances. 
To allow performance optimization of instruction execution, the IA-32 architecture allows departures from strong-
ordering model called processor ordering in Pentium 4, Intel Xeon, and P6 family processors. These processor-
ordering variations (called here the memory-ordering model) allow performance enhancing operations such as 
allowing reads to go ahead of buffered writes. The goal of any of these variations is to increase instruction execu-
tion speeds, while maintaining memory coherency, even in multiple-processor systems.
Section 8.2.1 and Section 8.2.2 describe the memory-ordering implemented by Intel486, Pentium, Intel Core 2 
Duo, Intel Atom, Intel Core Duo, Pentium 4, Intel Xeon, and P6 family processors. Section 8.2.3 gives examples