Changes between Version 72 and Version 73 of processus_thread

Timestamp:

Feb 8, 2018, 3:21:04 PM (7 years ago)

Author:

alain

Comment:

--

processus_thread

@@ -151 +151 @@
 == __6) Process 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 work is done by a RPC thread executing in the owner cluster.
+The destruction of process P can be caused by a sys_exit() system call executed by any thread of process P,  or by a signal send by another process executing the sys_kill() system call. In both case, the work must be done by a thread running in the owner cluster, because all process copies must be involved, and the list of copies is rooted in the owner cluster. If the sys_kill() - or sys_exit() - function is not called in the owner cluster, an RPC is sent to the owner cluster.
 
+=== 6.1 parent / child synchronization
+
+A child process destruction must be reported to the parent process. This reporting is done by the blocking sys_wait() system call, executed by the parent process. The actual child destruction cannot be done before the parent calls the sys_wait() function. As the '''sys_wait()''' function, and the '''sys_kill() / sys_exit()''' function are executed by different threads running in different clusters, this requires a "rendez-vous": The first arrived thread block and deschedule, and must be reactivated by the other thread. This synchronisation uses three specific fields in the process descriptor: the "wait_lock" field is a remote_spin_lock; the "wait_status" field contains the status returned by the child process; the "wait_done"field is a Boolean indicating that the parent thread is waiting.
+
+ * Both the thread executing the sys_exit() / sys_kill() function, and  the thread executing the sys_wait() function)try to take the "wait_lock" implemented in the child process descriptor (the "wait_lock" in the parent process is not used. 
+ * The child registers its exit value in the T thread "join_value" field, and test the JOIN_DONE flag in the T thread "flags" field: 
+   * If the ''wait_done'' flag is set, the PT thread arrived first and is blocked: the T thread reset the  BLOCKED_EXIT bit in the PT thread (using the extended pointer stored in the "join_xp" field), reset the JOIN_DONE flag, releases the "join_lock" in T thread, and exit as described in the DETACHED case. 
+   * If the JOIN_DONE flag is not set, the T thread T arrived first: the T thread set the BLOCKED_JOIN bit in the T thread "blocked" field, releases the "join"lock", and deschedules.
+ * The PT thread test the BLOCKED_JOIN bit in T thread:
+   * If the BLOCKED_JOIN bit is set, the T thread arrived first and is blocked: the PT thread reset the BLOCKED_JOIN bit in the T thread, get the exit value from the T thread i "join_value" field, releases the "join_lock" in T thread, and continue. 
+   * If the BLOCKED_JOIN bit is not set, the PT thread arrived first: the PT thread register its extended pointer in the T thread "join_xp" field, set the JOIN_DONE flag in the T thread, sets the BLOCKED_EXIT bit in the PT thread "blocked" field, releases the "join_lock" in the T thread, and deschedules.
 === 6.1) process exit ===
 
-To handle the exit( value ) system call, the client thread, executing the sys_exit() function, send the RPC_PROCESS_EXIT to the owner cluster of the client process. We use a RPC even if the thread executing the exit() is running in the owner cluster, because the killer thread cannot be the client thread. From this point all the work is done by the RPC in owner cluster.
+To handle the exit( value ) system call, the client thread, executing the sys_exit() function, send the RPC_PROCESS_EXIT to the owner cluster of the client process. 
 
 === 6.2) process kill ===