Browse Prior Art Database

CHECKING Mechanism for Shared Resource Allocator in a Distributed Environment

IP.com Disclosure Number: IPCOM000042295D
Original Publication Date: 1984-May-01
Included in the Prior Art Database: 2005-Feb-03
Document File: 3 page(s) / 16K

Publishing Venue

IBM

Related People

Giroir, D: AUTHOR [+2]

Abstract

The checking mechanism is to be used in a system where a plurality of users share a common resource the allocation of which is performed by means of a distributed arbitration mechanism. The checking mechanism insures that only one user will be granted access to the shared resource. As shown in Fig. 1, the shared resource can be a tri-state bus the access of which by a plurality of N units is controlled through a distributed arbitration mechanism. The arbiter checker, like the arbiter itself, is distributed over units connected to the tri-state bus. Distributed portions of the checker are called checker members, and distributed portions of the arbiter are called arbiter members. Checker members communicate with their counterparts, the arbiter members, and exchange information between themselves for verification purposes.

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

Page 1 of 3

CHECKING Mechanism for Shared Resource Allocator in a Distributed Environment

The checking mechanism is to be used in a system where a plurality of users share a common resource the allocation of which is performed by means of a distributed arbitration mechanism. The checking mechanism insures that only one user will be granted access to the shared resource. As shown in Fig. 1, the shared resource can be a tri-state bus the access of which by a plurality of N units is controlled through a distributed arbitration mechanism. The arbiter checker, like the arbiter itself, is distributed over units connected to the tri-state bus. Distributed portions of the checker are called checker members, and distributed portions of the arbiter are called arbiter members. Checker members communicate with their counterparts, the arbiter members, and exchange information between themselves for verification purposes. Each checker member has access to a so-called checking mark. This mark is built from dedicated lines called checking bus lines 1, shared among the checker members. Its goal is to hold the granted unit name. Each unit is given a specific name, unique among the pool of potential users of the bus. A checker member becomes active as its relevant arbiter member N preselected for shared bus ownership; this starts the checking process. In case of arbitration error, multiple checker members may become active. Once a checker member is made active, it proceeds to the subsequent operations, as shown in Fig. 2: 1. It fills in the checking mark with the granted unit name. In case of multiple active checker members, the checking mark will collect multiple unit names mixed together. 2. After a delay which enables any active checker member to access the checking mark to fill in its relevant granted unit name, the verification phase proceeds; each of the active checker members reads in the checking mark and compares it with its unit name. Two cases may occur: a) No arbitration error: a unique checker member is active, and the checking mark still holds the active unit's name. In that case, this active user is allowed to get hold of the shared bus. b) Arbitration error: multiple checker members are active, and the checking mark does not hold a single unit name but a mix of names. Each checker member does not get positive comparison between the checking mark contents and its own unit name. Then, an error is to be reported. Three conditions must be met for making sure the checking mechanism works properly: 1. The checker members must work synchronously over each unit. 2. The checking mark must be written in such a mode as its contents reflect the superimposition of all granted unit names. For example, if names are represented by a binary code, the checking mark contents will be the result of the logical OR between granted unit names. 3. User names are built by either one or a combination of multiple symbols out of a symbol set. An example of two symbol names...