of Task T Evaluate - Design and verification of distributed tasking supervisors for concurrent

T'CALLABLE Z Z Z Z Z Z ~ ATTR REQ MSG (CALLABLE MSG = TRUE) Z Z Z Z Z Z ~ Get Status of T = ATTR REPLY MSG (ATTR VALUE = result)

= Return Result

Figure 22: Message Transaction for Evaluation of Attribute CALLABLE.

M and P are dierent tasks in the example, it is necessary for P to send a message to M notifying M of the activation of a dependent M must then send an acknowledgment to P. In the rst message, MSG SOURCE is set to the name of the task which activated the dependent (e.g., task P in the above example), while the MSG DEST is set to the name of the master of the activated dependent (e.g., task M in the above example). The CLASS value of this message is DEPENDENT MSG, and its variant has three compo- nents. The DEPENDENT NAME component is the name of the activated dependent the DEPENDENT NODE component is the node location to which the activated dependent was assigned. The MASTER SCOPE component indicates the nesting level in the master task which contains the corresponding access type denition.

The reply message has a CLASS value of DEPENDENT REPLY MSG and no variant the MSG SOURCE and MSG DEST are set opposite to the settings in the DEPEN- DENT MSG. Figure 24 is a Weatherly-style diagrammatic depiction of the message transaction described above, using the tasks of Figure 23.

declare task M

task body M is

task type T TYPE

type T REFis access T TYPE task bodyT TYPE is taskP

task bodyP is T :T REF begin

T := newT TYPE

;; T.

all

is a direct dependent of M, not P. endP begin end M begin end

Figure 23: Remote Activation of Dependent Tasks.

4.5.6 Messages for the Terminate Alternative

The major defect of the Weatherly protocol is its lack of support for the

terminate

alternative. Consider the execution of a selective wait with a

terminate

alternative by some task T. Assume that either T has no dependents, or else that the dependents of T are either terminated or are themselves waiting at a

terminate

alternative. It is a consequence of the termination semantics dened in Section 9.4 of the Ada Language Reference Manual (LRM) that T must communicate with its master M in order to determine whether or not it is able to execute its

terminate

alternative. Three new messages (AT TERM MSG, TERM REQ MSG and TERM CONFIRM MSG) and two new execution status values (WAIT FOR ENTRY TERMINATE and WAIT FOR TERMINATE CONFIRMATION) have been added to the Weatherly protocol to implement the

terminate

alternative. Some of the terminology used for this implementation is taken from Jha and Kafura JK85,Kaf85].

4.5. THE SUPERVISOR MESSAGE-PASSING PROTOCOL 71

Task P

Task M

Allocate T.

all

Z Z Z Z Z Z ~ DEPENDENT MSG

(DEPENDENT NAME = ID for T.

all

) Z Z Z Z Z Z ~Store Dependent Name in Local Entry for M = DEPENDENT REPLY MSG = Update Global Map With Entry for M

Figure 24: Message Transaction for Remote Activation of a Dependent.

The

terminate

alternative is complicated because of its nondeterministic nature, since it is possible for some task T waiting at a

terminate

alternative to be called by a task located \exterior" to the task dependency tree that is being terminated.

The functions of the new messages are as follows:

1. AT TERM MSG: This message informs T's master M that T is waiting at an open

terminate

alternative. The status of T changes to WAIT FOR ENTRY TERMI- NATE after the message is sent.

2. TERM REQ MSG: This message requests an immediate indication from M as to whether or not all conditions have been satised for T to execute its

terminate

alternative. The status of T changes to WAIT FOR TERMINATE CONFIRMA- TION after the message is sent.

3. TERM CONFIRM MSG: The reply to a TERM REQ MSG or AT TERM MSG. The BOOLEAN component CONFIRMED of the variant for this message indicates

whether or not permission to terminate has been granted by M.

The TERM CONFIRM MSG is sent in reply to an AT TERM MSG only when a termination decision is made by M based on some eventual change in the status of the dependency tree of which it is the root. On the other hand, the TERM CONFIRM MSG is immediately sent in reply to a TERM REQ MSG, because the TERM REQ MSG forces M to make a termination decision based on the current status of its dependency tree.

To enable a task to correctly determine when termination conditions have been satised, the execution status of the dependents of each such M is recorded in the DEPENDENTS component of the local map entry for M (see Figure 15). The following execution status values are dened for each dependent status record:

1. AWAITING ACTIVATION: The dependent has not yet been activated, or else it is executing its declarative part.

2. ACTIVATED: The dependent is executing its body.

3. AWAITING TERMINATION: The dependent is waiting at a

terminate

alternative, indicated by M's receipt of an AT TERM MSG from the dependent.

4. AWAITING TERMINATION CONFIRMATION: M has received from the dependent a TERM REQ MSG, indicating that the dependent received an entry call after reaching a

terminate

alternative. At this point only M has the power to allow or disallow the dependent to accept the entry call, since M may have already decided to carry out termination of its dependency tree.

5. PENDING TERMINATION: The dependent has been told to execute its

terminate

alternative equivalently, M has sent the dependent a TERM CONFIRM MSG with the CONFIRMED component set to TRUE.

6. TERMINATED: The dependent has terminated.

The need for both an AWAITING TERMINATION dependent status value and an AWAIT- ING TERMINATION CONFIRMATION status value is related to the issuance of a termination decision by M with a TERM CONFIRM MSG. If the decision is to conrm termination to dependents, both AWAITING TERMINATION and AWAITING TERMI- NATION CONFIRMATION dependents must be notied of this decision. On the other

4.5. THE SUPERVISOR MESSAGE-PASSING PROTOCOL 73

Task T

Task M

(T's Master) Reach Executable

Terminate

Alternative Z Z Z Z Z Z Z ~ AT TERM MSG Z Z Z Z Z Z Z ~ Change Status of T ... Termination Conditions Become Satised = TERM CONFIRM MSG (CONFIRMED = TRUE) = Execute_Alternative

Terminate

Figure 25: Message Transaction for Execution of a

Terminate

Alternative.

hand, if the decision is to deny termination to dependents, only AWAITING TERMI- NATION CONFIRMATION dependents must be notied of this decision, since AWAIT- ING TERMINATION dependents are still passively suspended waiting at a

terminate

alternative.

In every case, the MSG SOURCE and MSG DEST component settings correspond in an obvious way to the two communicants of each message transaction. The complete al- gorithm for distributed execution of the

terminate

alternative has been given in detail in Appendix D. Figures 25, 26 and 27 are Weatherly-style diagrammatic depictions of the possible message transactions each gure depicts the message transactions between a task T waiting at a

terminate

alternative and T's master M. Figure 25 depicts the case of a

Task T

Task M

In document Design and verification of distributed tasking supervisors for concurrent programming languages (Page 87-92)