TASK-TO-TASK COMMUNICATION

STP contains two areas used for intertask communication. The first area is the communication module chain control (CMCC); the second area is the communication module (CMOO).

The CMCC is a contiguous area containing an entry for each combination of tasks possible within the system. The CMCC is arranged in task number sequence, that is, all possible task 0 combinations of requests to task 0 are followed by all possible combinations of requests to task 1. The task 10 of the requesting task and the task 10 of the requested task are the values that determine the appropriate CMCC entry.

CMOOs are allocated from a pool as needed and, therefore, have no fixed location. Memory pool 2 is reserved exclusively for use by intertask communications. A CMOO consists of six words: two are used for control;

two are used as input registers; and two are used as output registers. A task receives ftll of its requests and makes all of its replies through a CMOO.

Figure 3-1 illustrates the tables used for task communication.

One task communicates with another by placing a request in the input word of a CMOO. The requested task replies by placing the request status in the output words of the CMOO. The format of a request is subject to the requirements defined by the called task. Requests recognized by a task are described with the task later in this section. However, some

conventions do exist. Conventionally, the requested function is placed in INPUT+O. Output usage is conventionally defined such that OUTPUT+O is

o

if no error has occurred; otherwise, it contains a nonzero error code.

Six reentrant routines in STP that are common to all tasks facilitate intertask communication. They are:

PUTREQ Put request routine, asynchronous; destroys A6.

GETREQ Get request routine; destroys A6 and A7.

PUTREPLY Put task reply routine; destroys A6 and A7.

GETREPLY Request status routine; destroys A6.

SM-0040 3-3 ^C

TASK COMMUNICATION SYSTEM TASK PROCESSOR Communication Module Chain Control

Task 0

.---

---Header Task 1

, , ,

Task 0 to Task 1

, , , ,

Task 1 to Task 1

, , , , _{, ,}

, ^, _{, , ,}

Task 2 to Task 1

---, , ,

_{I I I I}

I I

, ,

I I

1

, , , _,

Task n to Task 1

Task n

, ,

\

Communication Modules L+

CMOD 1 ^,~

"

Task 2 to Task 1

"

^{1---- Control}

--~

_" " "

"

^Input

"

^1----

--l+ CMOD 2

,,' " "

Task 2 to Task 1 ---- Output

---

~---.

~

·

· ·

r--l+

CMOD n Task 2 to Task 1

Figure 3-1. Task communication tables

SM-0040 3-4 c

SYSTEM TASK PROCESSOR TASK COMMUNICATION

TSKREQ Task request routine, synchronous: destroys A3.

REPLIES Queues unrequested reply; destroys A6.

The task placing a request calls PUTREQ to place the request and calls GETREPLY to check for a status from the requested task. Conversely, the requested task uses GETREQ to locate outstanding requests and uses

PUTREPLY to return the status. If TSKREQ is used, PUTREQ and GETREPLY must not be used.

TSKREQ is incompatible with PUTREQ and GETREPLY; if TSKREQ is used, PUTREQ and GETREPLY must not be.

PUTREQ

This STP common subroutine places the request in the input registers of a CMOD and links the appropriate communications module chain control. If

the request cannot be chained because no CMODs are available or the chain is at its maximum, PUTREQ suspends the calling task or, at the caller's discretion, returns control to the requester with no action taken. Once PUTREQ bas successfully generated the CMOD and linked it to the CMCC, the requested task is readied and control returns to the requester. PUTREQ is called through a return jump with the caller providing the following values.

INPUT REGISTERS: (AI) Discard indicator. If (AI) is positive, control does not return to the caller until the request

is queued. If (AI) is negative and the request cannot be queued without suspending the caller, control returns with no action taken.

(A2) Requested task's ID (Sl) INPUT+O

Request (S2) INPUT+l

OUTPUT REGISTERS: None GETREQ

This STP common subroutine locates any outstanding request for the caller. Using the CMCC, GETREQ searches for a CMOD representing a request not yet given to the requester. GETREQ begins the CMCC search with the lowest numbered task and returns the first request encountered

to the caller. A task calls GETREQ through a return jump.

SM-0040 ^{3-5 C}

TASK COMMUNICATION SYSTEM TASK PROCESSOR

INPUT REGISTERS: None

OUTPUT REGISTERS: (AO) Found indicator. If (AO)=O, no outstanding requests exist. If ^(AO)~O, a request is returned.

(A2) 10 of task that generated the request (51) INPUT+O

Request (52) INPUT+1

PUTREPLY

This STP common subroutine places the reply to a request in the first available CMOD. Requests and replies are stored in the CMOO in the sequence in which they are generated. Therefore, a single CMOD

represents an unrelated request and reply. The subroutine readies the task where the reply is directed and returns to the requester. PUTREPLY is called through a return jump.

INPUT REGISTERS: (A2) 10 of task to receive the reply (51) OUTPUT+O

Reply (52) OUTPUT+l

OUTPUT REGISTERS: None GETREPLY

This STP common subroutine searches for a reply to the calling task. The search begins with the lowest numbered task and ends with the highest numbered task, returning the first reply encountered. GETREPLY removes the CMOO from the CMCC and releases it for reallocation. The subroutine

is called through a return jump.

INPUT REGISTERS: None

OUTPUT REGISTERS: (AO) Found indicator. If (AO)=O, no reply is located; if (AO)~O, a reply is returned to the caller.

(A2) ID of replying task

SM-0040 3-6 C

I

SYSTEM TASK PROCESSOR TASK COMMUNICATION

(Sl) OUTPUT+O

Reply (S2) OUTPUT+l

TSKREQ

This STP common subroutine makes a request to a task for processing and suspends the caller until a reply is received. If the request cannot be queued immediately, because either the queue is at its maximum or because no communication modules are available, the caller is suspended until the request is queued. Once the request is queued, the caller is suspended until a reply is received. TSKREQ is called through a return jump. If one task makes a request to another using TSKREQ, all requests from the first task to the second must be made using TSKREQ. Mixed use of TSKREQ and PUTREQjGETREPLY can cause unpredictable results.

INPUT REGISTERS: (A2) 10 of requested task (Sl) INPUT+O

Request (S2) INPUT+l

OUTPUT REGISTERS: (Sl) OUTPUT+O

Reply (S2) OUTPUT+l

REPLIES

This subroutine queues a reply for which no corresponding request has been made. The reply is queued at the beginning of the reply queue. A reply sent through this subroutine is seen by GETREPLY before any reply sent through PUTREPLY.

INPUT REGISTERS: (AI) Discard indicator. If (AI) is positive, control does not return to the caller until a reply is queued. If (AI) is negative and the reply cannot be queued without suspending the caller, control returns with no action taken.

(A2) 10 of task to receive the reply (Sl) INPUT+O

Reply (S2) INPUT+l

OUTPUT REGISTERS: None

SM-0040 3-7

c

I

TASK COMMUNICATION SYSTEM TASK PROCESSOR

Im Dokument CRAY-1® AND CRAY X-MP COMPUTER SYSTEMS (Seite 155-160)