![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Fast Rendezvous Optimization Normally the accept body of an Ada rendezvous is executed only in the context of the acceptor task. The fast rendezvous optimization executes the accept body in the context of the caller task. This optimization reduces the number of thread context switches that need to be executed by the underlying microkernel.
Note: The Fast Rendezvous optimization is not supported by the ts3 version of the runtime archive library.
Following is an overview of the optimization: if the acceptor task gets to the accept statement before the caller task makes the call, the acceptor task saves its register and stack context, switches to a wait stack, and does an Ada_Krn_I.Task_Wait. When the caller task gets around to doing the accept call, it saves its register and stack context, restores the acceptor task's register and stack context and returns to execute the accept body. When the end of the accept body is reached, the caller task overwrites the current register and stack context into the acceptor task's area, does an Ada_Krn_I.Task_Signal of the acceptor task, restores the caller task's register and stack context, and returns to the code in the caller task. Eventually, when the signaled acceptor task is scheduled to run, it restores the acceptor task's register and stack context (this context was updated by the caller task to be at the point where the call was made to finish the accept body) and returns to the code in the acceptor task after the call was made to finish the accept body.
Two configuration parameters are in v_usr_conf to control the fast rendezvous optimization:
When using the debugger, the fast rendezvous optimization (accept body is executed by the caller task) has a few subtle differences from the normal rendezvous case (accept body is executed by the acceptor task).
Following is an example to illustrate the differences. There are two tasks doing a repetitive rendezvous. The caller task is Rendezvous_Send. The acceptor task is Rendezvous_Receive. A breakpoint has been placed in the acceptor body. There are two cases: either the breakpoint is reached when the acceptor task (Rendezvous_Recieve) is executing the accept body or the caller task (Rendezvous_Send) is executing the acceptor body. Here is the debugger output for the two cases.
Case 1: At breakpoint when the acceptor task is executing the accept body (normal rendezvous)
[1] stopped at "/vc/test/task_rend2.a":15 in rendezvous_receive >lt Q TASK NUM STATUS rendezvous_send 3 in rendezvous rendezvous_receive[2].receive_item * rendezvous_receive 2 executing in rendezvous with rendezvous_send[3] at entry receive_item >lt all Q TASK NUM STATUS rendezvous_send 3 in rendezvous rendezvous_receive[2].receive_item thread id = 14002bce8 Ada tcb address = 140026fd8 Static priority = 0 Current priority = 0 parent task : <main program>[1] * rendezvous_receive 2 executing in rendezvous with rendezvous_send[3] at entry receive_item ENTRY STATUS TASKS WAITING receive_item - no tasks waiting - thread id = 140026de0 Ada tcb address = 1400220d0 Static priority = 0 Current priority = 0 parent task : <main program>[1]
Case 2: At breakpoint when the caller task is executing accept body (fast rendezvous)
[1] stopped at " /vc/test/task_rend2.a ":15 in rendezvous_receive >lt Q TASK NUM STATUS rendezvous_send 3 doing rendezvous for rendezvous_receive[2].receive_item * rendezvous_receive 2 executing in rendezvous via rendezvous_send[3] at entry receive_item >lt all Q TASK NUM STATUS rendezvous_send 3 doing rendezvous for rendezvous_receive[2].receive_item thread id = 14002bce8 Ada tcb address = 140026fd8 Static priority = 0 Current priority = 0 parent task : <main program>[1] * rendezvous_receive 2 executing in rendezvous via rendezvous_send[3] at entry receive_item ENTRY STATUS TASKS WAITING receive_item - no tasks waiting - thread id = 140026de0 Ada tcb address = 1400220d0 Static priority = 0 Current priority = 0 parent task : <main program>[1]
Here are the subtle differences for the fast rendezvous, case 2:
- Even though the breakpoint occurred in the Rendezvous_Send task, Rendezvous_Receive is still displayed as the current breakpointed task. You can select the caller task and still get the caller's call stack and see where it was making the rendezvous call from.
- The STATUS for Rendezvous_Send is "doing rendezvous" instead of "in rendezvous". This indicates that the caller task is executing the accept body. The second line for Rendezvous_Receive is "in rendezvous via" instead of "in rendezvous with". This indicates that the caller task is executing the accept body.
- The only misleading piece of information is the current underlying thread that is executing. The debugger says that Rendezvous_Receive is the currently executing task. From this you would assume that its thread, 2, is the current one. However, for the fast rendezvous case, it is really Rendezvous_Send's thread, 3.
For more information on the hierarchy of runtime archives see Library Selection.
Rational Software Corporation http://www.rational.com support@rational.com techpubs@rational.com Copyright © 1993-2002, Rational Software Corporation. All rights reserved. |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |