Changes between Version 43 and Version 44 of rpc_implementation


Ignore:
Timestamp:
Oct 3, 2019, 3:40:24 PM (3 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • rpc_implementation

    v43 v44  
    7474Only 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.
    7575Therefore, 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:
    76 1. allocate itself an array of RPC descriptors rpc[N] in client cluster (one per target server),
     761. allocate itself an array of RPC descriptors rpc[N] in client cluster (N is the number of target servers),
    77771. allocate itself a shared responses counter in client cluster (can be in client stack),
    78781. initialize itself the N RPC descriptors, as well as the responses counter (N expected responses),
     
    8888
    8989In order to avoid deadlocks, for each core, ALMOS-MKH defines a private pool of RPC threads  associated to one single RPC_FIFO[i,k].
    90 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.
     90If 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.
    9191
    9292The 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).