Changes between Version 21 and Version 22 of processus_thread

Timestamp:

Jul 15, 2016, 8:08:29 PM (8 years ago)

Author:

alain

Comment:

--

processus_thread

@@ -23 +23 @@
 There is a partial list of informations stored in a process descriptor (process_t in ALMOS-MK):
 - '''PID''' :  proces identifier.
-- '''PPID''' : parent process identifier,
-- '''XMIN, YMIN, XMAX, YMAX''' : rectangle covering all active clusters. 
+- '''PPID''' : parent process identifier, 
 - '''PREF''' : extended pointer on the reference process descriptor.
 - '''VMM''' : virtual memory manager containing the PG_TBL and the VSEG_LIST.
@@ -126 +125 @@
 == __5) Thread destruction__ ==
 
-The destruction of a thread T running in cluster K can be caused by the thread itself, with the pthread_exit() system call. It can also be caused by a kill signal, went by anothprthread,  requesting the thread to stop execution. In both case, the host kernel K is in charge of the destruction. The scenario is more complex if the finishing thread T is running in ATTACH mode, because the parent thread TP must be informed of the completion of thread T, in case of pthread_join() executed by TP.
+The destruction of a thread T running in cluster K can be caused by the thread itself, with the pthread_exit() system call. It can also be caused by a kill signal, sent by another thread,  requesting the thread to stop execution. In both case, the host kernel K is in charge of the destruction. The scenario is more complex if the finishing thread T is running in ATTACH mode, because the parent thread TP must be informed of the completion of thread T, in case of pthread_join() executed by TP.
 
 === 5.1) phase 1 ===
@@ -141 +140 @@
 In each cluster, a dedicated kernel thread is in charge of housekeeping: This thread releases the memory allocated to all DEAD threads.
 
-== __5) Destruction d’un processus__
+== __5) Process destruction__ ==
+
+The process destruction can be caused by an exit() system call, or by asignal send by another process.
+In both case, the owner cluster is in charge of the destruction.
 
 === 5.1) phase 1 ===
 
-Si l’appel système exit() est exécuté sur un cluster K différent du cluster Z propriétaire, le noyau du cluster K envoie une TASK_EXIT_RPC vers le cluster Z propriétaire.
-L’argument est le PID du processus P.
+If the exit() system call is executed by a thread running in a cluster K different from the owner cluster Z, the kernel K send a RPC_PROCESS_REQ_EXIT to cluster Z. The argument is the PID.
 
 === 5.2) phase 2 ===
 
-Pour exécuter la TASK_EXIT_RPC, le noyau du cluster Z propriétaire de P broadcaste une TASK_EXIT_RPC vers tous les clusters M qui contiennent au moins un thread du processus P. 
-Dans chaque cluster M, le noyau recevant une TASK_EXIT_RPC enregistre le signal KILL dans les descripteurs detous les threadsde P.
-Quand il détecte que la TRDL(P,M) est vide, il libère toutes les structures de données allouées au processus P dans le cluster M, et retourne la réponse au cluster Z.
+To execute this RPC, the owner kernel Z send a multi-cast  RPC_PROCESS_EXIT to all clusters X that contain a copy of the process descriptor, using its COPIES_LIST. The argument of this RPC is the PID.
 
 === 5.3) phase 3 ===
 
-Lorsque toutes les réponses au TASK_EXIT_RCP ont été reçues par le cluster Z, celui-ci libère toutes les structures 
-de données allouées au processus P dans le cluster Z.
+In each cluster X, the kernel receiving a RPC_PROCESS_EXIT register the kill signal in all threads descriptors associated to the PID process. and polls the local TH_TBL(X,P). When it detects that the TH_TBL(X,P) is empty, it releases the memory allocated to process descriptor, and acknowledges the RPC to cluster Z.
+
+=== 5.4) phase 4 ===
+
+When the kernel Z has received all expected responses to the multi-cast RPC, it releases all memory located to process PID in cluster Z, and this completes the process destruction.