gtpc3m12 | Concepts and Structures |
A useful abstraction for describing the dispatching of processing work in a
tightly coupled multiprocessing environment is shown in Figure 24. This abstraction suppresses the fact that in reality,
the CPU loop program
comes in two versions: one version is given an affinity to the main
I-stream engine and the other version is shared by all other I-stream
engines. The distinction between the two versions is not necessary to
describe the action taken on cross list items. In Figure 24, I-stream engines are shown as "CPU n" because this
is the way they are identified in online system tables.
The ideas emphasized in Figure 24 are:
- Multiple I-stream engines (CPUs) share main storage.
- A single program, the CPU loop in this case, in shared main storage can be
executed by all of the several I-stream engines. The execution can
occur simultaneously.
- Data in shared main storage, which is unique to an I-stream engine (the
cross list in this case), is accessed using Page 0 referencing.
- All I-stream engines have access through pointers in the I-stream status
table to the cross lists on each of the other I-stream engines.
Processor locking must be invoked to protect data that is modified in the
tables associated with a cross list. Notice that although there are
multiple cross lists, they are shared by (that is, accessible to) all I-stream
engines. A program executing in any I-stream engine can add an item to
the cross list of any other I-stream engine, but only a program executing in
an I-stream engine with a Page 0 reference to its own cross list is permitted
to remove an item from a cross list.
- A single flow chart, Figure 18 in particular, represents execution sequences that can occur on
all I-stream engines. In following a specific instance of I-stream
engine switching, the flow chart remains the same, but you must
associate different I-stream engines with different paths on the flow
chart.
- In a uniprocessing environment of just the main I-stream engine, the flow
is still valid.
Also, remember that most of the main storage resident control program is
reentrant across I-stream engines, but is only serially reusable within an
I-stream engine. Keeping all of the previous ideas in mind is not
always easy. After reflecting upon Figure 24, you should be ready to consider the following description
of I-stream engine switching.
Conceptually, the cross lists represent a communication mechanism (mail
boxes of sorts) for moving processing work among I-stream engines in a tightly
coupled multiprocessing environment. Each I-stream engine must be given
the location of every other cross list, a rudimentary form of routing.
The cross list references are done through the I-stream status table; the
pointers to this table are handled during system initialization. During
IPL, each I-stream engine is assigned a number known as the I-stream engine
ID. This ID is, for example, placed in a field in an ECB and is passed
from one I-stream engine to another through system control blocks such as
IOBs. This permits a response to be returned to the I-stream engine on
which a request was made; for example, the results of servicing a tape
I/O request.
All processing work transferred to another I-stream engine must be done by
means of a cross list, which reduces the amount of locking that would be
necessary if all CPU loop lists could be accessed by any I-stream
engine. Furthermore, multiple cross lists reduce the number of
instructions needed to find an item of work for any given I-stream
engine; scanning and processor IDs would be required if there was a
single shared cross list.
The structure of a cross list item reveals the essence of the cross
list interface. An item on a cross list has the following 4-byte
fields:
- Field
- Definition
- Parameter 1
- The data in this field is particular to the post-interrupt routine that is
to receive control.
- Parameter 2
- The data in this field is particular to the post-interrupt routine that is
to receive control.
- Forward pointer
- The items in the cross list are forward chained.
- Backward pointer
- The items in the cross list are backward chained.
- PI vector
- This field points to the routine that is given control when the item of
work reaches the top of the cross list.
- I/S originator
- This field identifies the I-stream engine from which the processing work
originated. It is used primarily by system tracing facilities.
Figure 24. Multiple I-Stream Engine Processing Abstraction
An outline of the procedure for moving an Entry from the main I-stream
engine to an application I-stream engine is given in Step 4c. COMM SOURCE Invokes the Application. The detailed processing flow when the SWISC macro is
executed on the main I-stream engine as well as subsequent processing follows
here:
- COMM SOURCE issues an SWISC macro request on the main I-stream
engine. The SWISC macro expansion is found in the routing control
application table (RCAT).
The SWISC macro input
parameters, in this case, include the name of the program segment to be
entered and the option to allow the load balancing routine to select the
I-stream engine on which the Entry should be dispatched. As a result of
electing to execute the Entry on an application I-stream engine, the need
arises to place a work item on the ready list of an application I-stream
engine.
In switching an Entry, the Entry is always dispatched from the
ready list and not directly from the cross list. The cross list is the
highest priority dispatch list and is used for control program services of
relatively short duration, with the goal of keeping the list empty or
short. An item is only removed from a list when the work associated
with a previous item has completed or is suspended. Although an Entry
is characterized as expeditious processing, an Entry is a long-running process
in comparison to control program services.
- The SWISC service routine, executing on the main I-stream engine, uses the
$ADPC macro (add to designated list in designated I-stream) to build the
following parameters:
- The address of the routine to be placed in the post-interrupt (PI) vector
field
of the cross list item on the application I-stream engine. This PI
vector identifies a routine that will ultimately add an item to a designated
list in the application I-stream engine; in this case, the ready
list.
- The ID of the I-stream engine to receive the work.
- The storage block address to be added to the application I-stream
engine's ready list; in this case, the ECB.
- The PI vector to locate the routine to be invoked from the ready list of
the application I-stream engine; in this case, the termination of the
SWISC service routine. Do not confuse this with the value placed in the
PI vector field of the cross list itself.
- The $ADPC macro service routine always passes four parameters to the
$CRISC (add to cross list in designated I-stream)
macro service routine, which, in this case, places a four-field item on the
cross list of the designated I-stream engine.
- When the item reaches the top of the cross list on the application
I-stream engine, the PI vector to $ADPC (the PI vector of the cross list)
causes the terminating portion of the $ADPC routine to receive control, which
places the ECB address and the PI vector to the SWISC routine on the ready
list, and a return is made to the top of the CPU loop
program.
- The two-field item of ECB addr and PI to SWISC is
now at the bottom of the application I-stream engine's ready list.
When this item reaches the top of the ready list, the terminating portion of
the SWISC service routine that was originally invoked on the main I-stream
engine is given control. This terminating routine is the equivalent of
an ENTDC (enter and drop all existing programs) macro request.
Starting an Entry on the application I-stream engine requires the use of
the control transfer interface to get from OPZERO to COMM SOURCE on the main
I-stream engine, the SWISC macro to place an item on the cross list of the
application I-stream engine, and the ENTDC macro service routine to invoke the
first segment of an application package on the application I-stream
engine. Although the SWISC macro is always invoked by COMM SOURCE on
the main I-stream engine, in a uniprocessing environment, the Entry is never
switched but is dispatched from the ready list of the engine in which the
SWISC macro is issued, because the ID of the engine to receive the work is the
main I-stream engine itself. This can also happen in a multiple
I-stream engine environment if, for example, all the application I-stream
engines are busier than the main I-stream engine.
To uncover the processing sequence to handle an I/O request, consider the
case where an Entry, executing on an application I-stream engine, uses a FINDC
macro request followed by a WAITC macro request. You should now refer
to Figure 18, and keep the description provided by Figure 24 in mind.
- The FINDC macro service routine creates an IOB
that points to the ECB of the requesting Entry and is used to control an I/O
operation on behalf of the Entry.
- If the DASD device needed to complete the request is busy, the IOB is put
on the device queue. If the DASD device is not busy, the I/O is started
immediately from the I-stream that issued the FINDC request.
- The FINDC service routine, running on an application I-stream
engine, restores registers with the register save area found in the active
ECB. Thereafter, the old SVC PSW is loaded and processing continues in
the entry on the application I-stream engine from which the FINDC I/O request
was made.
- The entry ultimately issues the WAITC macro request. If the I/O has
not started (because the device queue contained other IOBs) or the I/O has not
completed, the ECB will be suspended and another entry will be dispatched on
the I-stream.
- If the DASD device to which the I/O was queued was busy, the I/O will
eventually be started by the I-stream that processed the last interrupt for
the IOB before our FINDC request on that device.
- Finally, the I/O will be completed and issue an I/O interrupt on any
I-stream. By using the $ADPC macro, the IOB is put back on the ready
list of the I-stream that initially issued the FINDC macro.
- When the IOB reaches the top of the ready list, the FINDC post-interrupt
routine is called to place a pointer in the ECB that locates the data read
from disk. This routine also releases the main storage block used to
hold the IOB. Assuming no other I/O is pending, a return is made to the
entry that issued the FINDC macro request. If additional I/O is pending
for the ECB, control is returned to the CPU loop.