Browse Prior Art Database

System Support for Multiprocessing Without an Atomic Storage

IP.com Disclosure Number: IPCOM000119555D
Original Publication Date: 1991-Feb-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 6 page(s) / 227K

Publishing Venue

IBM

Related People

Van Fleet, JW: AUTHOR

Abstract

Semaphores or locking on a Multiprocessing (MP) system, such as the IBM System/370, are often supported with CPU and memory hardware which provide an atomic access to storage with both a read and a write operation. Two examples are the 'Compare and Swap' and 'Test and Set' instructions. These instructions guarantee that every processor will access the same data in memory. Additionally, the processor organization and implementation also guarantee that the cache in each processor will reflect the changes. Other architectures use "bus lock" and "bus unlock" instructions to guarantee atomic access to memory. There are external lockboxes which control access to shared memory.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 22% of the total text.

System Support for Multiprocessing Without an Atomic Storage

      Semaphores or locking on a Multiprocessing (MP) system,
such as the IBM System/370, are often supported with CPU and memory
hardware which provide an atomic access to storage with both a read
and a write operation.  Two examples are the 'Compare and Swap' and
'Test and Set' instructions. These instructions guarantee that every
processor will access the same data in memory.  Additionally, the
processor organization and implementation also guarantee that the
cache in each processor will reflect the changes.  Other
architectures use "bus lock" and "bus unlock" instructions to
guarantee atomic access to memory.  There are external lockboxes
which control access to shared memory.

      This article outlines hardware and associated software support
which could provide the capability to program tightly coupled MP
support without an atomic storage operation and without hardware
maintained cache consistency.
The topics covered are:
         Software Locking Attributes
         Functions of the Hardware associated with locking
         Potential advantages/disadvantages.

      The key to this capability is a hardware lock mechanism which
maintains lockword status outside of any single processor (and
outside main memory) but with communication paths to all processors.
There need be no communications path with main memory from the Lock
Hardware.  The essential ingredient of the Lock Hardware is that
releasing the lockword triggers flushing of local processor cache so
that at the completion of the lock operation, data would be
consistent for all processors.  Of course, since the hardware does
NOT guarantee atomic operations, the software conventions along with
the Lock Hardware would be necessary to keep data consistency.
(Note: Mach strategy is to allow reading without holding locks.  Such
a strategy can be accommodated within this definition.  It should be
clear, however, that accessing data without holding the corresponding
lock must be done with due regard to the potential inconsistency of
the underlying data.  In particular, without cache consistency, it
would be necessary to explicitly flush cache in conjunction with
reading such data.)

      SOFTWARE LOCKING ATTRIBUTES

      The required hardware must provide a minimum of an atomic
switch setting outside the confines of main memory.  With this
minimum, software can implement a variety of locking protocols which
will provide the basis for the required serialization and
synchronization for the system.  Hardware enhancements would
implement portions of the locking protocols for the operating system.
These enhancements would provide performance and/or RAS improvements.

      The complete software locking structure and mechanism mechanism
definition itself is not defined in this proposal.  The locking
architecture would, at least, cover:
      1.  Deadlock
     ...