4.5.3 Rendezvous Port
Rendezvous is a function for synchronization and communication between tasks, supporting the procedures for making processing requests by one task to another and for returning the processing result to the requesting task. The object for which both of these tasks wait is called a rendezvous port. The rendezvous function is typically used to realize task communication in a client/server model, but can also support more .exible synchronization and communication models.
Functions are provided for creating and deleting a rendezvous port, issuing a processing request to a rendezvous port (call rendezvous), accepting a processing request from a rendezvous port (accept rendezvous), returning the processing result (reply rendezvous), forwarding an accepted processing request to another rendezvous port (forward rendezvous to other port), and referencing rendezvous port status and rendezvous status. A rendezvous port is identi.ed by an ID number called a rendezvous port ID. A task issuing a processing request to a rendezvous port (the client-side task) calls a rendezvous, specifying a message (called a call message) with information about the rendezvous port, the rendezvous conditions, and the processing being requested. The task accepting a processing request on a rendezvous port (the server-side task) accepts the rendezvous, specifying the rendezvous port and rendezvous conditions.
The rendezvous conditions are indicated in a bit pattern. If the bitwise logical AND of the bit patterns on both sides (the rendezvous conditions bit pattern of the task calling a rendezvous for a rendezvous port and the rendezvous conditions bit pattern of the accepting task) is not 0, the rendezvous is established. The state of the task calling the rendezvous is WAIT on rendezvous call until the rendezvous is established. The state of the task accepting a rendezvous is WAIT on rendezvous acceptance until the rendezvous is established.
When a rendezvous is established, a call message is passed from the task that called the rendezvous to the accepting task. The state of the task calling the rendezvous goes to WAIT for rendezvous completion until the requested processing is completed. The task accepting the rendezvous is released from WAIT state and it performs the requested processing. Upon completion of the requested processing, the task accepting the rendezvous passes the result of the processing in a reply message to the calling task and ends the rendezvous. At this point the WAIT state of the task that called the rendezvous is released. A rendezvous port has separate queues for tasks waiting on rendezvous call (call queue) and tasks waiting on rendezvous acceptance (accept queue). Note, however, that after a rendezvous is established, both tasks that formed the rendezvous are detached from the rendezvous port. In other words, a rendezvous port does not have a queue for tasks waiting for rendezvous completion. Nor does it keep information about the task performing the requested processing.
T-Kernel assigns an object number to identify each rendezvous when more than one is established at the same time. The rendezvous object number is called the rendezvous number. The method of assigning rendezvous numbers is implementation-dependent, but at a minimum information must be included for specifying the task that called the rendezvous. Numbers must also be uniquely assigned to the extent possible; for example, even if the same task makes multiple rendezvous calls, the .rst rendezvous and second rendezvous must have di.erent rendezvous numbers assigned.
Rendezvous is a synchronization and communication function introduced in the ADA programming language, based on Communicating Sequential Processes (CSP). In ADA, however, the rendezvous function is part of the language speci.cation and therefore has a di.erent role than in T-Kernel, which is a real-time kernel speci.cation. The rendezvous ports provided by the real-time kernel are OS primitives by which an ADA rendezvous capability is implemented. Since the ADA rendezvous function di.ers from that in the T-Kernel speci.cation in a number of ways, the T-Kernel-speci.cation rendezvous functions cannot necessarily be used to implement the ADA rendezvous.
Rendezvous operation is explained here using the example in Figure 4.5. In this figure Task A and Task B are running asynchronously.
- If Task A .rst calls tk_cal_por, Task A goes to WAIT state until Task B calls tk_acp_por. The state of Task A at this time is WAIT on rendezvous call (a).
- If, on the other hand, Task B .rst calls tk_acp_por, Task B goes to WAIT state until Task A calls tk_cal_por. The stat of Task B at this time is WAIT on rendezvous acceptance (b).
- A rendezvous is established when both Task A has called tk_cal_por and Task B has called tk_acp_por. At this time Task A remains in WAIT state while the WAIT state of Task B is released. The state of Task A is WAIT for rendezvous completion.
- The Task A WAIT state is released when Task B calls tk_rpl_rdv. Thereafter both tasks enter a run state.
Figure 4.5: Rendezvous Operation
As an example of a specific method for assigning rendezvous object numbers, the ID number of the task calling the rendezvous can go in the low bits of the rendezvous number, with the high bits used for a sequential number.
While it is true that the rendezvous functionality can be achieved through a combination of other synchronization and communication functions, better e.ciency and ease of programming are achieved by having a dedicated function for cases where the communication involves an acknowledgment. One advantage of the rendezvous function is that since both tasks wait until message passing is completed, no memory space needs to be allocated for storing messages.
The reason for assigning unique rendezvous numbers even when the same task does the calling is as follows. It is possible that a task, after establishing a rendezvous and going to WAIT state for its completion, will have its WAIT state released due to timeout or forcible release by another task, then again call a rendezvous and have that rendezvous established. If the same number were assigned to both the .rst and second rendezvous, attempting to terminate the .rst rendezvous would end up terminating the second rendezvous. If separate numbers are assigned to the two rendezvous and the task in WAIT state for rendezvous completion is made to remember the number of the rendezvous for which it is waiting, error will be returned when the attempt is made to terminate the .rst rendezvous.
Comments