Changes between Version 100 and Version 101 of processus_thread


Ignore:
Timestamp:
Jun 26, 2018, 12:50:32 PM (6 years ago)
Author:
nicolas.van.phan@…
Comment:

Add links to referenced files and structures

Legend:

Unmodified
Added
Removed
Modified

  • processus_thread

    v100 v101  
    1414As ALMOS-MKH supports process migration, the '''reference cluster''' can be different from the '''owner cluster'''. The '''owner cluster''' cannot change (because the PID is fixed), but the '''reference cluster''' can change in case of process migration.
    1515
    16 In each cluster K, the local cluster manager ( cluster_t  type in ALMOS-MKH ) contains a process manager ( pmgr_t  type in ALMOS-MKH ) that maintains three structures for all processes owned by K :
     16In each cluster K, the local cluster manager ( [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/kernel/kern/cluster.h cluster_t] type in ALMOS-MKH ) contains a process manager ( [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/kernel/kern/cluster.h pmgr_t]  type in ALMOS-MKH ) that maintains three structures for all processes owned by K :
    1717 * The '''PREF_TBL[lpid]''' is an array indexed by the local process index. Each entry contains an extended pointer on the reference process descriptor.
    1818 * The '''COPIES_ROOT[lpid]''' array is also indexed by the local process index. Each entry contains the root of the global list of copies for each process owned by cluster K.   
    … …  
    2525 * '''KILLED''' : the process received a SIGKILL signal. It will be destroyed by the parent process executing a wait() sys call.
    2626
    27 You can find below a partial list of information stored in a process descriptor ( process_t in ALMOS-MKH ):
     27You can find below a partial list of information stored in a process descriptor ( [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/kernel/kern/process.h process_t] in ALMOS-MKH ):
    2828- '''PID''' :  proces identifier.
    2929- '''PPID''' : parent process identifier,
    … …  
    4343== __2) Thread definition__ ==
    4444
    45 ALMOS-MKH defines four types of threads :
     45ALMOS-MKH defines in [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/kernel/kern/thread.h thread_type_t] four types of threads :
    4646 * one '''USR''' thread is created by a pthread_create() system call.
    4747 * one '''DEV''' thread is created by the kernel to execute all I/O operations for a given channel device.
    … …  
    5858This 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.
    5959
    60 You can find below a partial list of information stored in a thread descriptor (thread_t in ALMOS-MKH):
     60You can find below a partial list of information stored in a thread descriptor ([https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/kernel/kern/thread.h thread_t] in ALMOS-MKH):
    6161 * '''TRDID''' : thread identifier
    6262 * '''TYPE''' : KERNEL / USER / IDLE / RPC
    … …  
    8282=== 3.1) fork() ===
    8383
     84See [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/kernel/syscalls/sys_fork.c sys_fork.c].
     85
    8486The fork() system call is the only method to create a new process. A thread of parent process P, running in a cluster X,  executes the fork() system call to create a child process C on a remote cluster Y, that will  become both the owner and the reference cluster for the C process. A new process descriptor, and a new thread descriptor are created and initialized in target cluster Y for the child process.
    8587The calling thread  can run in any cluster. If the target cluster Y is different from the calling thread cluster X, the calling thread uses a RPC to ask the target cluster Y to do the work, because only the target cluster Y can allocate memory for the new process and thread descriptor.
    … …  
    102104=== 3.2) exec() ===
    103105
     106See [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/kernel/syscalls/sys_exec.c sys_exec.c]
     107
    104108After a fork() system call, any thread of a process P can execute an exec() system call. This system call forces the P process to execute a new application, while keeping the same PID, the same parent process, the same open file descriptors, and the same environment variables. The existing P process descriptors (both the reference and the copies)  and all associated threads will be destroyed. A new process descriptor and a new main thread descriptor are created in the reference cluster, and initialized from values found in the existing process descriptor, and from values contained in the .elf file defining the new application. The calling thread  can run in any cluster. If the reference cluster Z for process P is different from the calling thread cluster X, the calling thread must use a RPC to ask the reference cluster Z to do the work.
    105109
    … …  
    108112== __4) Thread creation__ ==
    109113
     114See [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/kernel/syscalls/sys_thread_create.c sys_thread_create.c]
     115
    110116Any user thread T of any process P, running in any cluster K, can create a new thread NT in any cluster K'. This creation is initiated by the ''pthread_create'' system call.
    111  * The target cluster K' can be specified by the user application, using the CXY field of the pthread_attr_t argument. If the CXY is not defined by the user, the target cluster K' is selected by the kernel K, using the DQDT.
     117 * The target cluster K' can be specified by the user application, using the CXY field of the [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/kernel/syscalls/shared_include/shared_pthread.h pthread_attr_t] argument. If the CXY is not defined by the user, the target cluster K' is selected by the kernel K, using the DQDT.
    112118 * The target core in cluster K' can be specified by the user application, using the CORE_LID field of the pthread_attr_t argument. If the CORE_LID is not defined by the user, the target core is selected by the target kernel K'.
    113119
    … …  
    115121
    116122 * If the target cluster K' does not contain a copy of the P process descriptor, the kernel K' creates a process descriptor copy from the reference P process descriptor, using a remote_memcpy(), and using the cluster_get_reference_process_from_pid() to get the extended pointer on reference cluster. It allocates memory for the associated structures GPT(M,P), VSL(M,P), FDT(M,P).  These structures being used as read-only caches will be dynamically filled by the page faults. This new process descriptor is registered in the COPIES_LIST and in the LOCAL_LIST.
    117  * When the local process descriptor is set, the kernel K' select the core that will execute the new thread, allocates a TRDID to this thread, creates the thread descritor, and registers it in the local process descriptor, and in the selected core scheduler.
     123 * When the local process descriptor is set, the kernel K' select the core that will execute the new thread, allocates a TRDID to this thread, creates the thread descriptor, and registers it in the local process descriptor, and in the selected core scheduler.
    118124
    119125== __5) Thread destruction__ ==
    120126
    121 The destruction of a target thread T can be caused by another thread K, executing  the ''pthread_cancel()'' sys call requesting the target thread T to stop execution. It can be caused by the thread T itself, executing the ''pthread_exit()'' sys call to suicide. Finally, it can be caused by the ''exit()'' or ''kill()'' syscalls requesting the destruction of all threads of a given process.   
     127The destruction of a target thread T can be caused by another thread K, executing  the '''pthread_cancel()''' sys call (see [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/kernel/syscalls/sys_thread_cancel.c sys_thread_cancel.c]) requesting the target thread T to stop execution. It can be caused by the thread T itself, executing the '''pthread_exit()''' sys call (see [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/kernel/syscalls/sys_thread_exit.c sys_thread_exit.c]) to suicide. Finally, it can be caused by the ''exit()'' or ''kill()'' syscalls requesting the destruction of all threads of a given process.
    122128
    123129The unique method to destroy a thread is to call the '''thread_kill()''' function, that set the THREAD_FLAG_REQ_DELETE bit in the ''flags'' field of the target thread descriptor. The thread will be asynchronously deleted by the scheduler at the next scheduling point.
    124130The scheduler calls the ''thread_destroy()'' function that detach the thread from the scheduler, detach the thread from the local process descriptor, and releases the memory allocated to the thread descriptor. The '''thread_kill()''' function can be called by the target thread itself (for an exit), or by another thread (for a kill).
    125131
    126 If the target thread is running in attached mode, the '''thread_kill()''' function synchronize with the joining thread, waiting the actual execution of the pthread_join() syscall before marking the target thread for delete.
     132If the target thread is running in attached mode, the '''thread_kill()''' function synchronize with the joining thread, waiting the actual execution of the pthread_join() (see [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/kernel/syscalls/sys_thread_join.c sys_thread_join.c]) syscall before marking the target thread for delete.
    127133
    128134If the target thread is main thread (i.e. the thread 0 in the process owner cluster) the  '''thread_kill()''' does not mark the target thread for delete, because this must be done by the parent process main thread executing the ''sys_wait()'' syscall (see section [6] below).   
    … …  
    154160== __6) Process destruction__ ==
    155161
    156 The destruction of a process P can be caused by a sys_exit() system call executed by any thread of process P,  or by another process executing the sys_kill(SIGKILL) system call. It can also be caused by a CtrlC signal typed on the process terminal. In all cases, the work must be done for all process copies in all clusters, using the list of copies rooted in the owner cluster.
     162The destruction of a process P can be caused by a [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/kernel/syscalls/sys_exit.c sys_exit()] system call executed by any thread of process P,  or by another process executing the [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/kernel/syscalls/sys_kill.c sys_kill(SIGKILL)] system call. It can also be caused by a CtrlC signal typed on the process terminal. In all cases, the work must be done for all process copies in all clusters, using the list of copies rooted in the owner cluster.
    157163
    158164=== 6.1) parent / children synchronization
    … …  
    160166The process descriptors copies (other than the process descriptor in owner cluster) are simply deleted by the scheduler when the last thread of a given process in a given cluster is  deleted. The process descriptor copy is removed from the list of copies in the owner process cluster descriptor, and the process copy disappears.
    161167
    162 The process destruction in the owner cluster is more complex, because the child process destruction must be reported to the parent process when the main thread of the parent process executes the blocking sys_wait() system call (in the parent owner cluster). Therefore, the child process in owner cluster cannot be destroyed before the parent calls the sys_wait() function. As the '''sys_wait()''' function, and the '''sys_kill()''' or '''sys_exit()''' function are executed by different threads running in different clusters, this requires a parent/child synchronization. To keep a process descriptor in ''zombi'' state after a sys-kill() or sys_exit(), the main thread (i.e. thread 0 in process owner cluster) is not deleted until the sys_wait() syscall is executed by the parent process main thread.  This synchronization uses the '''term_state'''  field in process descriptor, that contains the following informations :
     168The process destruction in the owner cluster is more complex, because the child process destruction must be reported to the parent process when the main thread of the parent process executes the blocking [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/kernel/syscalls/sys_wait.c sys_wait()] system call (in the parent owner cluster). Therefore, the child process in owner cluster cannot be destroyed before the parent calls the sys_wait() function. As the '''sys_wait()''' function, and the '''sys_kill()''' or '''sys_exit()''' function are executed by different threads running in different clusters, this requires a parent/child synchronization. To keep a process descriptor in ''zombi'' state after a sys-kill() or sys_exit(), the main thread (i.e. thread 0 in process owner cluster) is not deleted until the sys_wait() syscall is executed by the parent process main thread.  This synchronization uses the '''term_state'''  field in process descriptor, that contains the following informations :
    163169 * the PROCESS_FLAG_KILL  indicates that a KILL request has been received by the child; 
    164170 * the PROCESS_FLAG_EXIT indicates that an EXIT  request has been made by the child;