Changes between Version 80 and Version 81 of processus_thread

Timestamp:

Feb 27, 2018, 4:12:36 PM (6 years ago)

Author:

alain

Comment:

--

processus_thread

@@ -51 +51 @@
 From the point of view of scheduling, a thread can be in three states : RUNNING, RUNNABLE or BLOCKED. 
 
-This implementation of ALMOS-MKH does not support thread migration: a thread created by a pthread_create() system call is pinned on a given core in a given cluster. The only exception is the main thread of a process, that is automatically created by the kernel when a new process is created, and follows its owner process in case of process migration.
-
-In a given process, a thread is identified by a fixed format TRDID identifier, coded on 32 bits : The 16 MSB bits (CXY) define the cluster where the thread has been pinned. The 16 LSB bits (LTID) define the thread local index in the local TH_TBL[K,P] of a process descriptor P in a cluster K. This LTID index is allocated by the local process descriptor when the thread is created.
+In a given process, a thread is identified by a fixed format TRDID kernel identifier, coded on 32 bits : The 16 MSB bits (CXY) define the cluster K where the thread has been created. The 16 LSB bits (LTID) define the thread local index in the local TH_TBL[K,P] of a process descriptor P in a cluster K. This LTID index is allocated by the local process descriptor when the thread is created.
 
 Therefore, the TH_TBL(K,P) thread table for a given process in a given clusters contains only the threads of P placed in cluster K. The set of all threads of a given process is defined by the union of all TH_TBL(K,P) for all active clusters K.
 To scan the set off all threads of a process P, ALMOS-MKH traverse the COPIES_LIST of all process_descriptors associated to P process. 
+
+This implementation of ALMOS-MKH does not support thread migration: a thread is pinned on a given core in a given cluster. In the future process migration mechanism, all threads of given process in a given cluster can migrate to another cluster for load balancing. This mechanism is not implemented yet (february 2018), and will require to distinguish the kernel thread identifier (TRDID, that will be modified by a migration), and the user thread identifier (THREAD, that cannot be modified by a migration). In the current implementation, the user identifier (returned by the pthread_create() sys call, is identical to the kernel identifier.
 
 There is a partial list of informations stored in a thread descriptor (thread_t in ALMOS-MKH):
@@ -120 +120 @@
 == __5) Thread destruction__ ==
 
-The destruction of a thread T running in cluster K can be caused by another thread K, executing  the thread_kill() function requesting the target thread to stop execution. It can also be caused by the thread T itself, executing the thread_exit() function to suicide. It can also be caused by the sys_exit() or sys_kill() syscalsl requesting the destruction of all threads of a given process.    
+The destruction of an user thread T can be caused by another thread C, executing  the ''pthread_cancel()'' sys call requesting the target thread to stop execution. It can also be caused by the thread T itself, executing the ''pthread_exit()'' sys call to suicide. Finally, it can also be caused by the ''exit()'' or ''kill()'' syscalsl requesting the destruction of all threads of a given process.    
 
 === 5.1) thread kill ===
 
-The '''thread_kill()''' kernel function is executed by a killer thread that must be different from the target thread, but must run be running in the same cluster as the target thread. This function can be called by the ''pthread_cancel'' system call, to destroy one single thread, or by the ''kill'' system call, (through the process_kill() function), to destroy all threads of a given process. The killer thread requires the target thread scheduler to do the work by writing in the target thread descriptor, and the target scheduler signals completion to the killer by writing in the killer thread descriptor. 
+The '''thread_kill()''' kernel function is executed by a killer thread that must be different from the target thread, and must be running in the same cluster as the target thread. The killer thread requires the target thread scheduler to do the work at the next scheduling point, by writing in the target thread descriptor, and the target scheduler signals completion to the killer by writing an acknowledge in a specified location in the killer stack. 
 
- * To request the kill, the killer thread  sets the BLOCKED_GLOBAL bit in the target thread "blocked" field, sets the SIG_KILL bit in the target thread "signals" field, and register in the target thread "kill_xp" field the extended pointer on the killer thread.
+ * To request the kill, the killer thread  sets the BLOCKED_GLOBAL bit in the target thread "blocked" field, sets the SIG_KILL bit in the target thread "signals" field, and registers in the target thread "ack_rsp_count" field a pointer on the location where the acknowledge must be written.
  * If the target thread is running on another core than the killer thread, the killer thread send an IPI to the core running the target thread, to ask the target scheduler to handle the request. If the target is running on the same thread as the killer, the killer thread calls directly the sched_handle_signal() function.
  * In both cases, the sched_handle_signals() function - detecting the SIG_KILL signal - detach the target thread from the scheduler, detach the target thread from the local process descriptor, detach the target thread from the parent thread if it is attached, release the memory allocated to the target thread descriptor, and atomically decrement the response counter in the killer thread to signal completion.