Changes between Version 48 and Version 49 of rpc_implementation

Timestamp:

Jan 12, 2020, 1:31:45 PM (4 years ago)

Author:

alain

Comment:

--

rpc_implementation

@@ -85 +85 @@
 The behavior on the server side is not modified for a parallel RPC.
 
-== 6) Pool of RPC servers ==
+== 6) Pool of RPC threads ==
 
 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 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. 
+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. 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).