Changes between Version 51 and Version 52 of processus_thread

Timestamp:

Dec 7, 2017, 12:02:15 PM (6 years ago)

Author:

alain

Comment:

--

processus_thread

@@ -128 +128 @@
 === 5.1) thread_exit ===
 
- * If T is running in DETACHED mode, the calling thread T sets the FLAG_SUICIDE bit in the "flags" bit_vector, registers the BLOCKED_GLOBAL bit in the "blocked" bit_vector, and de-schedule. The scheduler, detecting the FLAG_SUICIDE bit, remove the thread from the scheduler list, remove the thread from its process, and destroys the thread descriptor.
+ * If it is running in DETACHED mode, the calling thread T sets the FLAG_SUICIDE bit in the "flags" bit_vector, registers the BLOCKED_GLOBAL bit in the "blocked" bit_vector, and de-schedule. The scheduler, detecting the FLAG_SUICIDE bit, remove the thread from the scheduler list, remove the thread from its process, and destroys the thread descriptor.
  * If it is running in ATTACHED mode, the calling thread T sets the BLOCKED_EXIT bit in the "blocked" bit vector and de-schedule.  The FLAG_KILL bit in the "flags" bit-vector,  and the BLOCKED_EXIT bit are set by the parent thread TP (using remote  accesses) when it executes the pthread_join(), and detects the BLOCKED_EXIT bit in thread T. The scenario is then the kill scenario described below.
 
@@ -138 +138 @@
 == __6) Process destruction__ ==
 
-The process destruction can be caused by an exit() system call, or by a signal send by another process.
-In both case, the owner cluster is in charge of the destruction.
+The destruction of process P can be caused by an exit() system call executed by any thread of process P,  or by a signal send by another process executing the kill() system call. In both case, the owner cluster is in charge of the destruction. 
 
-=== 6.1) phase 1 ===
+=== 6.1) process exit ===
 
-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.
+The exit() is a four steps scenario:
+ 1. 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_EXIT to cluster Z. The argument is the calling process PID.
+ 1. To execute this RPC, the owner kernel Z send a multi-cast  RPC_PROCESS_KILL to all clusters X that contain a copy of the process descriptor, using its COPIES_LIST. The argument of this RPC is the target process descriptor pointer.
+ 1. In each cluster X, the kernel receiving a RPC_PROCESS_KILL sets the FLAG_KILL bit signal in all threads descriptors associated to the target 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.
+ 1. When the kernel Z has received all expected responses to the multi-cast RPC_PROCESS_KILL, it releases all memory allocated to process PID in cluster Z, and deschedulethis completes the process destruction.
 
-=== 6.2) phase 2 ===
+=== 6.2) process kill ===
 
-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.
-
-=== 6.3) phase 3 ===
-
-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.
-
-=== 6.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.
+The kill() scenario is identical to the 4 steps exit() scenario above. It is initiated by a kill() system call executed by any thread running in any cluster.