GDSX Manual

Design and Development

Extended General Device Support (GDSX) Manual–134303

2-38

Semaphore Control

The purpose of a semaphore is to ensure the serial access of a shared resource. A task is

considered to have acquired a resource when it owns the semaphore associated with the

resource. TSCODE defines and maintains a checkpoint semaphore to guarantee that no

more than one task is doing a checkpoint at any given time. A unique user-defined

semaphore should be established for each resource requiring exclusive access. For

example, a semaphore may be used to control access to a global variable updated by

several tasks. Three utility procedures are available for managing semaphores other than

the checkpoint semaphore: INIT^SEM, PSEM, and VSEM. (The checkpoint

semaphore is defined by TSCODE and managed with the GET^CPSEM and

GIVE^CPSEM procedures.)

A semaphore is first initialized with INIT^SEM. The semaphore may be defined either

in global or extended memory; however, it is recommended that it be declared in global

memory, within a user private block, for example. If a backup GDSX process exists, the

semaphore must be initialized in both primary and backup GDSX processes. The

semaphore may then be acquired by calls to PSEM and released by calls to VSEM.

A task takes control of a semaphore when a call to PSEM inserts the address of the

task’s TCB (@TCB) into the first element of the semaphore structure (described in the

table below). If the semaphore is already owned, a task requesting ownership will have

its TCB address inserted at the end of a linked list of tasks waiting for the same resource

(tasks are linked via tcb.locklink); the task’s tcb.statex.wait^cause is set to 1; and the

task waits on DISP^RESOURCE. The linked list is also part of the semaphore structure,

which has the three elements shown in the following table:

For any semaphore other than the checkpoint semaphore, the VSEM procedure is used

to release the semaphore so that other tasks can use the associated resource. When a

task calls VSEM, TSCODE verifies that the caller owns the semaphore, then checks the

semaphore’s wait list. If this list is not empty, the first task on the list is given the

semaphore and a DISP^RESOURCE event is caused for the task.

A description of how tasks owning semaphores are restarted following a takeover is

given in "Takeover Processing" on page 2-33.

A user may wish to define a semaphore to ensure serial I/O to a disk file. This may be

accomplished in the USER^INITIALIZE exit by calls on ^OPEN and INIT^SEM to

Variable Name Description Contents

sem.semowner Current owner of

semaphore

0 if semaphore is available; owner’s TCB address

if semaphore is owned

sem.semhead Head of the wait list Address of SEMHEAD if no tasks are waiting;

otherwise, first waiter’s TCB address

sem.semtail Tail of the wait list Address of SEMHEAD if no tasks are waiting;

otherwise, last waiter’s TCB address

Caution. If a task owning one or more semaphores stops, the primary GDSX process stops.

If a task owning one or more semaphores faults with noretn equal to 1, the primary GDSX

process stops.