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

The ALERT routine (DMTSIG) also notifies another task
asynchronous event has taken place. In this case, DMTSIG is with an ALERT request element. GIVE/TAKE TASK-TO-TASK that an
not used While the ALERT method of
response from the alerted
for ordered enqueueing of
handled when the servicing immediate demand. task-to-task communication demands immediate
task, the GIVE/TAKE method provides a means
requests for services. These requests are
task is free to handle it, rather than upcn
Generally, request and response elements are formatted tables cf
information that reside in the storage of both the requesting task and
the task providing the service. During task-to-task communication,
these elements are passed from One task to another, containing either requests for services or responses to requests. When a task requests services of another task via GIVE/TAKE, it builds a GIVE table in its storage. The GIVE request buffer and a GIVE response
buffer. (The request and response buffers may te at the same locaticn
in storagee)
The GIVE request buffer contains a GIVE request element, which is a
table of information describing the service being requested. Once the GIVE request element is built, the requesting task clears the synch lock
in its address of the GIVE table to zero (in preparation for a call to DMTWAT) and sFecifies the address of the GIVE tatle in a call to DMTGIV. The supervisor then enqueues a supervisor GIVE element containing a
pointer to the GIVE table, so that the request can be forwarded to the
receiving task when that task is ready to accept the request. When the receiving task signals that it can process a GIVE request, the
receiving task builds a TAKE table in its own storage. The TAKE table
consists of a field to receive the task name of the requesting task and
the addresses and the lengths of a TAKE request buffer and a TARE response buffer. Functionally, these buffers complement the GIVE request and response buffers and, like the GIVE buffers, may be at tbe
same location in storage. Introduction 3-25