Browse Prior Art Database

Avoiding XI in Mp Systems Using Software Locks

IP.com Disclosure Number: IPCOM000037333D
Original Publication Date: 1989-Dec-01
Included in the Prior Art Database: 2005-Jan-29
Document File: 3 page(s) / 17K

Publishing Venue

IBM

Related People

Pomerene, JH: AUTHOR [+6]

Abstract

In multiprocessing systems the degradation due to cross interrogation on shared data can be avoided for a class of locked data. The nature of the management of the cache coherency in this case is detailed. In addition, the possible use of a particular strategy based on Delayed Invalidate (DI) and Cross-Cache-Update (XCU) in a two-level cache hierarchy is discussed.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 40% of the total text.

Page 1 of 3

Avoiding XI in Mp Systems Using Software Locks

In multiprocessing systems the degradation due to cross interrogation on shared data can be avoided for a class of locked data. The nature of the management of the cache coherency in this case is detailed. In addition, the possible use of a particular strategy based on Delayed Invalidate (DI) and Cross- Cache-Update (XCU) in a two-level cache hierarchy is discussed.

Using a standard WTWAX (Write Through Write Allocate Exclusive)-L1 cache, the processor attempting a store can be delayed in a Multiprocessing environment when the data in its cache is not held Exclusive. The time to upgrade the line to Exclusive is the result of the requirement that the data line be purged from all other caches in the system. The purpose of this purging is to maintain cache coherency. However, if no other processor can access the data during the period that it is accessed by the original processor, the requirement that the store be delayed is unnecessary. That is, with a suitable mechanism it is possible that the invalidation of the line in other caches may be suitably deferred (DI) or the copies of the line in other caches be subjected to cross-cache-updates (XCU). Whichever policy is followed it is necessary to assure that the proper action has occurred before the line can be accessed erroneously on another processor.

A new category of storage is proposed within the system and the cache lines from this category of storage are marked as locked-lines (LLs). If a line is labelled LL (by whatever means desired) the software assures that accesses to this line are serialized by a lock, i.e., no two processors will concurrently access/update the line since the accessor must "hold" the lock. There can be multiple locks and multiple areas of storage that are locked but there is no need to relate the lock to the area locked except that an area has only one lock. A lock may lock multiple areas.

When a LL is accessed for the purpose of a store the line can be updated without the promotion of the line to Exclusive since exclusivity of access is guaranteed by a higher authority.

All locks are assumed to be taken with an atomic update (CS/CDS/TS instructions in S/370) and can be released by any store operation to the lock- word. The assurance that the Deferred Invalidates (DIs) or the Cross-Cache- Updates (XCUs) are performed on a timely basis is based on the observation that at least one lock in the hierarchy of locks that restrict the access to any LL data that was updated is not in a LL. This observation follows from the fact that if the lock which controls a LL is in a LL, that line has a lock. Recurring on this observation implies an infinite number of locks or a lock in a non-LL. Further releasing of a lock is an access, any higher locks must still be held if the lock released is in a LL. Ultimately, the last lock released is not in a LL and this guarantees that the taking of this lock and its release was done w...