Changes between Version 53 and Version 54 of processus_thread


Ignore:
Timestamp:
Dec 8, 2017, 12:46:39 AM (6 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • processus_thread

    v53 v54  
    4444From the point of view of scheduling, a thread can be in three states : RUNNING, RUNNABLE or BLOCKED.
    4545
    46 This implementation of ALMOS-MK 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.
     46This 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.
    4747
    4848In 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.
    4949
    5050Therefore, 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.
    51 To scan the set off all threads of a process P, ALMOS-MK traverse the COPIES_LIST of all process_descriptors associated to P process.
     51To scan the set off all threads of a process P, ALMOS-MKH traverse the COPIES_LIST of all process_descriptors associated to P process.
    5252
    53 There is a partial list of informations stored in a thread descriptor (thread_t in ALMOS-MK):
     53There is a partial list of informations stored in a thread descriptor (thread_t in ALMOS-MKH):
    5454 * '''TRDID''' : thread identifier
    5555 * '''TYPE''' : KERNEL / USER / IDLE / RPC
    … …  
    128128=== 5.1) thread_kill() ===
    129129
    130 The thread_kill() function must be executed by a thread running in kernel mode in the same cluster as the target thread. It is called by the pthread_cancel() system call, to destroy one single thread, or by the kill() system call, to destroy all thread of a given process. The killer thread requires the target thread scheduler to do the job by writing in the target thread descriptor, and the target scheduler signals completion to the killer by writing in the killer thread descriptor.
     130The thread_kill() function must be executed by a thread running in kernel mode in the same cluster as the target thread. It is called by the ''pthread_cancel'' system call, to destroy one single thread, or by the ''kill'' system call, to destroy all threads of a given process. The killer thread requires the target thread scheduler to do the job by writing in the target thread descriptor, and the target scheduler signals completion to the killer by writing in the killer thread descriptor.
    131131
    132132 * 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_rsp" field the address of a response counter allocated in the killer thread stack.
    … …  
    141141 * The scheduler, detecting the SIG_SUICIDE bit, detach the thread from the scheduler, detach the thread from the local process descriptor, and releases the memory allocated to the thread descriptor.
    142142
    143 == 5.3) thread_exit when ATTACHED ===
     143== 5.3) thread_exit() when ATTACHED ===
    144144
    145 The thread_exit() scenario is more complex if the finishing thread T is running in ATTACHED mode, because another thread PT executing the pthread_join() system call must be informed of the exit of thread T. As the pthread_exit() can happen before of after the pthread_join(), this requires a synchronisation. This synchronisation uses three fields in thread descriptor:
     145The thread_exit() scenario is more complex if the finishing thread T is running in ATTACHED mode, because another - possibly remote - PT thread, executing the ''pthread_join'' system call, must be informed of the exit of thread T. As the ''pthread_exit'' can happen before of after the ''pthread_join'', this requires a synchronisation: The first arrived thread block and deschedule, and must be reactivated by the other thread. This synchronisation uses three specific fields in the thread descriptor: the "join_lock" field is a remote_spin_lock; the "join_value" field contains the exit value returned by the finishing thread T; the "join_xp"field contains an extended pointer on the PT thread that wants to join. The scenario is the following:
    146146
    147  remote_spin_lock implemented in the T thread descriptor,
    148 
    149  * The thread T try to take the locksets 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.
    150  * The thread PT try to take the lock
     147 * Both the T thread (executing the thread_exit() function), and the PT thread (executing the thread_join() function) try to take the "join_lock" implemented in the T thread descriptor (the "join_lock" in the PT thread is not used).
     148 * After taking the "join_lock", the T thread (running the thread_exit()  function) test the JOIN_DONE flag in T thread. If this flag is set, the PT thread arrived first: the T thread register its exit value in the PT thread "join_value" field, set the EXIT_DONE flag in the PT thread, reset the  BLOCKED_EXIT bit in PT thread (using the extended pointer stored in the "join_xp" field), release the "join_lock", and exit as described for the DETACHED case.
     149 * If the JOIN_DONE flag is not set, the thread T arrived first: The T thread register its exit value in the PT thread "join_value" field, release the "join"lock", blocks on the BLOCKED_JOIN and deschedules.
     150 * After taking the "join_lock", the PT thread (running the thread_join() function) test the EXIT_DONE flag in PT thread. If this flag is set, the T thread arrived first: the PT thread
     151reset the BLOCKED_EXIT bit in the T thread "blocked" field, get the exit value in the "join_value" field, reset the "join_lock" in T thread, and continue.
     152 * If the EXIT_DONE flag 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, releases the "join_lock" in the T thread, blocks on the BLOCKED_EXIT bit, and deschedules.
    151153
    152154== __6) Process destruction__ ==