Changes between Version 31 and Version 32 of rpc_implementation

Timestamp:

Apr 7, 2018, 3:32:35 PM (6 years ago)

Author:

alain

Comment:

--

rpc_implementation

@@ -26 +26 @@
 
 This RPC_FIFO has been designed to support a large number (N) of concurrent writers, an a small number (M) of readers:
- * N is the number of client threads (practically unbounded). A client thread can execute in any cluster, and can send a RPC request to any target cluster K. To synchronize these multiple client threads, each RPC_FIFO[i,k] implements a "ticket based" policy, defining a ''first arrived / first served'' priority to register a new request into a given RPC_FIFO[i,k].
- * M is the number of server threads in charge of handling RPC requests stored in a given RPC_FIFO[i,k]. M is bounded by the CONFIG_RPC_THREAD_MAX parameter. For each PRC_FIFO[i,k], it can exist several server threads, because we must avoid the ''head-of-line" blocking phenomenon, when a given server thread handling a given RPC is blocked on a given resource. To synchronize these multiple  server threads, the RPC FIFO implements a "light lock", that is a non blocking lock: only one RPC thread at a given time can take the lock and become the FIFO owner. When the light lock is taken by RPC thread T, another RPC thread T' failing to take the lock simply returns to IDLE state. 
+ * N is the number of client threads (practically unbounded). A client thread can execute in any cluster, and can send a RPC request to any target cluster K. To synchronize these multiple client threads, each RPC_FIFO[i,k] implements a ticket based policy, defining a first arrived / first served priority to register a new request into a given RPC_FIFO[i,k].
+ * M is the number of server threads in charge of handling RPC requests stored in a given RPC_FIFO[i,k]. M is bounded by the CONFIG_RPC_THREAD_MAX parameter. For each PRC_FIFO[i,k], it can exist several server threads, because we must avoid the ''head-of-line blocking'' phenomenon, when a given server thread handling a given RPC is blocked on a given resource. To synchronize these multiple  server threads, the RPC FIFO implements a ''light lock'', that is a non blocking lock : only one RPC thread at a given time can take the lock and become the FIFO owner, and another RPC thread T' failing to take the lock simply returns to IDLE state. 
  
 == 3) Client / Server Synchronization ==