Changes between Version 43 and Version 44 of rpc_implementation

Timestamp:

Oct 3, 2019, 3:40:24 PM (5 years ago)

Author:

alain

Comment:

--

rpc_implementation

@@ -74 +74 @@
 Only the behavior of the client has to be modified for a parallel RPC : To send parallel RPC requests to several servers, the client thread doe not block until the last request has been registered in the last server FIFO.
 Therefore, to request a RPC service XYZ in parallel mode to N servers, the client function does NOT use the ''rpc_xyz_client()'' function, and must implement the following client scenario:
-1. allocate itself an array of RPC descriptors rpc[N] in client cluster (one per target server),
+1. allocate itself an array of RPC descriptors rpc[N] in client cluster (N is the number of target servers),
 1. allocate itself a shared responses counter in client cluster (can be in client stack),
 1. initialize itself the N RPC descriptors, as well as the responses counter (N expected responses),
@@ -88 +88 @@
 
 In order to avoid deadlocks, for each core, ALMOS-MKH defines a private pool of RPC threads  associated to one single RPC_FIFO[i,k]. 
-If a given RPC thread extracted request[i] from the FIFO, but is blocked, waiting for a shared resource, the next request[i+i] in the FIFO can be extracted and handled by another RPC thread. In that case, the blocked RPC thread T releases the FIFO ownership before blocking and descheduling. This RPC thread T will complete the current RPC request when the blocking condition is solved, and the thread T is rescheduled. At any time, only one RPC thread has the FIFO ownership and can consume RPC requests from the FIFO. 
+If a given RPC thread extracted request[i] from the FIFO, but is blocked, waiting for a shared resource, the next request[i+i] in the FIFO can be extracted and handled by another RPC thread. In that case, the blocked RPC thread T releases the FIFO ownership before blocking and descheduling. This RPC thread T will resume when the blocking condition is solved, and the thread T is rescheduled. At any time, only one RPC thread has the FIFO ownership and can consume RPC requests from the FIFO. 
 
 The RPC threads are dynamically created - on demand - by the scheduler: When the RPC FIFO is not empty, an "idle"  RPC thread is scheduled to handle the pending RPC requests. If all existing RPC threads are blocked, a new RPC thread is dynamically created by the scheduler (in the ''shed_rpc_activate()'' function).