Changes between Version 18 and Version 19 of processus_thread


Ignore:
Timestamp:
Jul 15, 2016, 6:59:09 PM (8 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • processus_thread

    v18 v19  
    1 = Dynamic process and thread creation  =
     1= Process and thread creation/destruction  =
    22
    33[[PageOutline]]
     4
     5The process is the internal représentation of an user application. A process can be running as a single thread (called main thread), or can be multi-threaded. ALMOS-MK supports the POSIX thread API.
     6In this case the number of threads can be very large, and the threads of a given process can be distributed on all cores available in the shared memory architecture, for maximal parallelism. Therefore A single process can spread on all clusters. To avoid contention, the process descriptor of a P process, and the associated structures, such as the Page Table, or the Open File Descriptors Table  are  (partially) replicated in all clusters containing at least one thread of P.
    47
    58== __1) Process__ ==
    … …  
    710The PID (Process Identifier) is coded on 32 bits. It is unique in the system, and has a fixed format:  The 16 MSB (CXY) contain the owner cluster identifier. The  16 LSB bits (LPID) contain the local process index in owner cluster. The '''owner cluster''' is therefore defined by PID MSB bits.
    811
    9 To avoid contention, the process descriptor of a P process, and the associated structures, such as the Page Table, or the Open File Descriptors Table  are  (partially) replicated in all clusters containing at least one thread of P.
     12As it exists several copies of the process descriptors, ALMOS-MK defines a reference process descriptor, located in the '''reference cluster'''. The other copies are used as local caches,
     13and ALMOS-MK must guaranty the coherence betweenl the reference and the copies.
    1014
    11 As it exists several copies of the process descriptors, ALMOS-MK defines a reference process descriptor, located in the '''reference cluster''', and the other copies are used as local caches.
    12 
    13 '''Warning''' : to support process migration, the '''reference cluster''' can be different from the '''owner process'''.
     15'''Warning''' : to support process migration, the '''reference cluster''' can be different from the '''owner process''': the '''owner cluster'' cannot change (because the PID is fixed), but the '''reference
     16cluster'' can change in case of process migration.
    1417
    1518In each cluster K, the local cluster manager (cluster_t type in ALMOS-MK) contains a process manager (pmgr_t type in ALMOS-MK) that maintains three structures for all process owned by K :
    … …  
    123126== __5) Thread destruction__ ==
    124127
    125 The destruction of a thread TRDID running in cluster K can be caused by the thread itself, with the pthread_exit() system call. It can also be caused by a signal (local or remote) requesting the thread to stop execution. In both case, the host kernel K is in charge of the destruction.
     128The 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.
    126129
    127130=== 5.1) phase 1 ===
    128131
    129 
     132It T is running in ATTACH mode, the host cluster K force the T state to ZOMBI, to prevent the thread to be scheduled. If the thread completion is caused by an exit, the thread T stops immediately execution. If it is caused by a kill signal, the signal is registered in the thread descriptor, and the rescheduling will only occur at the next scheduling point.
     133If T is not running in attached mode, the scenario is similar, but the T is directly forced to the DEAD state.
    130134
    131135=== 5.2) phase 2 ===
    132136
    133 
     137This second phase is only required, in the parent thread cluster M, if T is running in ATTACH mode. The parent thread descriptor maintains a global list of all children threads running in ATTACH mode. When the parent thread execute the pthread_join() system call for a child identified by its TRDID, the M kernel scan this list to localize the selected child thread, and directly poll the child thread status using a remote_read access. When the M kernel detects the completion of T (ZOMBI state), it send a RPC_THREAD_USER_JOIN to the K cluster containing the T thread to ask the K kernel to change the state of T from ZOMBI to DEAD.   
    134138
    135139=== 5.3) phase 3 ===
    136140
    137  Le noyau du cluster K enregistre le signal KILL dans le descripteur de thread TRDID au moyen d’une opération atomique.
    138 Lors du traitement de ce signal, le thread TRDID est éliminé de l’ordonnanceur, il est éliminé de la TRDL(P,X), et  la mémoire
    139 allouée pour le descripteur de thread dans le cluster K est libérée.
     141In each cluster, a dedicated kernel thread is in charge of housekeeping: This thread releases the memory allocated to all DEAD threads.
    140142
    141143== __5) Destruction d’un processus__