Freescale Semiconductor PowerPC e500 Core, Reference Manual

Page: 166 / 548

PowerPC e500 Core Family Reference Manual, Rev. 1
3-36 Freescale Semiconductor
Instruction Model
— dcbst (The e500 broadcasts dcbst as a flush; if another processor implements dcbst as
a clean, the reservation is not cleared.)
3.3.1.7.2 Forward Progress
Forward progress in loops that use lwarx and stwcx. is achieved by a cooperative effort among
hardware, operating system software, and application software.
Book E guarantees one of the following when a processor executes a lwarx to obtain a reservation
for location X and then a stwcx. to store a value to location X:
1. The stwcx. succeeds and the value is written to location X.
2. The stwcx. fails because some other processor or mechanism modified location X.
3. The stwcx. fails because the processor’s reservation was lost for some other reason.
In cases 1 and 2, the system as a whole makes progress in the sense that some processor
successfully modifies location X. Case 3 covers reservation loss required for correct operation of
the rest of the system. This includes cancellation caused by some other processor writing
elsewhere in the reservation granule for X, as well as cancellation caused by the operating system
in managing certain limited resources such as real memory or context switches. It may also include
implementation-dependent causes of reservation loss.
An implementation may make a forward progress guarantee, defining the conditions under which
the system as a whole makes progress. Such a guarantee must specify the possible causes of
reservation loss in case 3. Although Book E alone cannot provide such a guarantee, the conditions
in cases 1 and 2 are necessary for a guarantee. An implementation and operating system can build
on them to provide such a guarantee.
Note that Book E does not guarantee fairness. In competing for a reservation, two processors can
indefinitely lock out a third.
3.3.1.7.3 Reservation Loss Due to Granularity
Lock words should be allocated such that contention for the locks and updates to nearby data
structures do not cause excessive reservation losses due to false indications of sharing that can
occur due to the reservation granularity.
A processor holding a reservation on any word in a reservation granule loses its reservation if some
other processor stores anywhere in that granule. Such problems can be avoided only by ensuring
that few such stores occur. This can most easily be accomplished by allocating an entire granule
for a lock and wasting all but one word.
Reservation granularity may vary for each implementation. There are no architectural restrictions
bounding the granularity implementations must support, so reasonably portable code must