gtpc3m1zConcepts and Structures

Loosely Coupled Multiprocessing -- A Database Perspective

Loosely coupled multiprocessing was incorporated in the TPF system to satisfy performance requirements; that is, the need to process more messages for each second, where most of the messages imply access to the same database, as in airline reservation systems. In a loosely coupled complex, each CPC has private main storage but all share the same module control units. Loosely coupled support provides additional MIPS for executing the shared set of application programs. Subsequently, tightly coupled multiprocessing was incorporated for the same reason; that is, to increase processing capacity. In both cases, the TPF system structure was influenced by the goal to permit multiple CPCs to process identical sets of application program segments and access a shared database.

Loosely coupled multiprocessing uses the external lock facility (XLF) to lock records that prevents data records from being updated simultaneously by multiple CPCs in a loosely coupled complex. These locks are set and interrogated by find and hold, find and unhold, and unhold macro service routines at a negligible impact to performance.

Record Hold Table and XLF Lock Table

To process a find and hold request in a loosely coupled complex, the TPF system first checks the main storage record hold table (unique to a CPC) to see if the record is already held by this CPC. If it is held, the request is queued; there is no need to check the XLF lock table until the record is unheld within this CPC. If the record is not held by this CPC, the TPF system holds the record for this CPC and checks the XLF lock table.

The reasons for maintaining a main storage record hold table are: