ASYNCHRONOUS INTERRUPTIONS AND EXITS Asynchronous interruptions result from processes external to RSCS. For example, during REX task execution, the RSCS operator may press the ATTN key on the Rses console, thereby asynchronously interrupting executicn
of the REX task.
To handle asychronous interruptions, RSCS tasks contain asynchronous
exit routines. These asychronous exit are set up during
initialization without dispatching the task being requested to perform
the req.uested service. Asynchronous exits are provided for external
interruptions, for certain I/O interruptions, and for ALERT requests
that occur during execution of another task.
Asynchronous exits are taken after a task calls DHTASY specifying the
requested exit conditions and the entry address of the asynchronous exit
routine. DHTASY also handles external interruptions reqeusted for the clock
comparator. The request element is queued on the asynchronous exit queue· and Frccessed by DHTEXT. The DMTASY clock comparator provides a time delay mechanism by using the CPU hardware clock comparator.
Asynchronous exit rOut1nes perform limited function, often enqueueing
requests for further processing at a later time by dispatched tasks. When the asynchronous exit routine completes processing, it returns
control to the Supervisor, which then resumes dispatching tasks via a
call to the dispatcher (DMTDSP). USING ASYNCHRONOUSLY REQUESTED SERVICES: DMTWAT Before a task can use the results of an asynchronously requested
service, it must ensure that the service has been performed. To ensure
that the service has been performed, the calling task signals that it is
waiting for completion of a service via a call to the supervisor routine DMTiAT, specifying the synch lock associated with the requested service.
If the high-order byte of the task's synch lock is nonzero when DMTiAT inspects it, control is returned directly to the calling task.
If the byte of the synch lock is zero, DMTiAT marks the
calling task nondispatchable (via the task's request element), stores
the address of the task's request element in the low-order bytes of the
synch lock, and resumes dispatching for other tasks. POSTING A SYNCHRONOUS LOCK When the requested service is complete the REX Task signals completicn ty calling the POST routine (DMTPST), specifying the requesting task's
associated synchronization lock. The POST routine sets the high-order byte of the synch lock to nonzero. This is referrred to as "posting" that synch lock, and indicates that the requested service is complete. RSCS Introduction 3-23
DISPATCHING IN RSCS The supervisor functions return control to the tasks by means of tbe
dispatcher (DMTDSP). The dispatcher scans the queue of tasks to be
executed (TASKE in SVECTORS), selects the first dispatchable task
element (that is, one that is not marked nondispatchable by DMTWAT), moves this task element to thp- end of task and restarts its
execution. If no task element is marked "nondispatchable," a masked-cn wait state PSi is loaded by the dispatcher.
In addition to posting a synch lock, DftTPST inspects the synch lock
to determine whether DMTWAT has stored the address of a task element in
that synch lock, implying that the task is nondispatchable. If this is
the case, DMTPST marks the task's task element dispatchable and clears
the last three bytes of the synch lock to zero.
Tasks may call DMTWAT specifying multiple synch locks. When this is
the case, each synch lock is inspected and, if any synch lock is posted,
task execution resumes immediately. If no synch locks are posted, the
task element for the calling task is marked nondispatchable, its address
is stored in each of the synchronization locks, and dispatching is
resumed for other tasks. When any synch lock in the list is posted, the task element is marked
dispatchable. The"dispatcher clears the low-order three tytes of each
of the task's synchronization locks (pointed to in the task element
tefore task execution is resumed).
Task-to-Task Communications
There are situations when a task requires the services of another task
in order to complete a function. For example, SML may require that AIS open a file for input before processing of that file can continue. RSCS task communicate with each other to request these kinds of services using two methods: ALERT task-to-task communication and communication.
Both methods use an element, Which is a tatle of information that
describes the nature of the request. In general, these elements are
referred to as request elements and ALERT elements.
ALERT TASK-TO-TASK COMMUNICATION The ALERT method of task-to-task communication allows
interrupt another task to request an immediate service.
request is described by an ALERT element, the address
specified by the requesting task in a call to DM1ASY. a task to
The type cf
of which is
The supervisor responds by giving control to the asynchronous exit routine defined by the request task and by passing to that task the
address of the ALERT element that describes the requested service.
The requested task's (that is, the task receiving the request)
asynchronous exit routine responds immediately and may copy the ALEET element into its own storage for further processing. The task's asynchroncus exit routine then returns control to the supervisor, which allows the dispatched task to resume execution. 370: System Logic and Problem Deterrnination--Volume 3
Previous Page Next Page