Filter
Top Products
v Issuing the SUSPEND call.
2. Task B performs the action by:
v Getting the parameters
v Performing the action
v Setting the results
v Terminating (or waiting for new work).
3. Task A ends the interaction by:
v Getting the results left by task B.
This sequence looks like:
Ignoring the Resume and Suspend, the execution amounts to:
where these actions are always sequential.
The synchronization protocol and task purge
If one of the tasks is to be purged, it is task A, because task A is the one
suspended. In this case, execution of task A after the failed SUSPEND would be in
parallel with task B; the proper serialization would be lost. If the program were left
unchanged, Process request and Set results would be taking place at the same
time as Get results, with unpredictable results.
One way of preventing this problem is to ensure that task A, if it is to be purged,
does not do anything that could interfere with task B. (This may well mean that
A must not detach, if doing so releases storage that B needs to access.) Because
the only task that is now involved is task B, B is left with the responsibility of
cleaning up for both tasks.
The sequence is:
Because task-purging is effective only if performed between SUSPEND and
RESUME, Suspend-fail precedes Resume-fail. This means that, with the same
constraints on serialization as in the normal synchronization protocol, the task-purge
protocol can be logically reduced to:
Task A: Set parameters Resume task B Suspend Get results
Task B: Get parameters Process request Set results Resume Detach
task A
Set parameters; Get parameters; Process request; Set results; Get results
Task A: Set parameters; Resume task B; Suspend-fail
Task B: Get parameters; Process request; Resume-fail; Clean up both
dispatcher functions
Chapter 3. The user exit programming interface (XPI) 301