| Now that we understand the relationship between processes and threads, we can consider the life cycle of a process. In this discussion, I use the term process instead of thread to make the discussions easier to follow. It is assumed that we understand that a thread can go to sleep while the process as a whole is still executing other threads. In this, we could assume that in these examples we are talking about a single thread process, where the state of the thread reflects the state of the entire process. Figure 11-2 shows us the major states the process can be in. The first thing to note is the names given to the states. These states are actually applied to threads. I used them to make the distinction between a runnable ( TSRUN ) thread and a running ( TSRUNPROC ) thread. Here's a brief explanation of the transition between states: -
Process is created with a fork() or vfork() system call. The child process is created with a single thread and contains an exact copy of the calling thread and its entire address space. vfrok() uses the address space while it performs an exec () . In this phase, you may see a process in a ps “l listing being in an Intermediate ( I ) state (the second field from the left). Once created, the thread will be marked as runnable . At this time, it joins one of a number of run queues (the number of run queues depends on how many processors are in the system). -
While waiting to run, a thread will gain priority. When a higher priority thread is ready to run, the kernel will context switch the current thread off the CPU in favor of the higher priority thread. -
While executing, a process can either be executing in kernel mode or user mode . In kernel mode, a thread is using some form of system call such as IO from disk, creating a new thread, allocating memory. When in user mode, a thread is performing some form of application-level processing. A process should spend most of its time in user mode . If so, it has all the resources it needs and doesn't need to perform IO or make any system calls. In such a situation, even if there are no other threads that want to run, a thread will be forced off the CPU by the kernel after every timeslice . At that point, if it is still the only thread that wants to run or is the thread with the highest priority, it will be the next thread allowed back on the CPU. If the thread needs to wait for an event to occur, e.g., IO from disk, the thread will be put to sleep by the kernel, waiting for IO. -
The thread has performed some activity that means the kernel has put it to sleep. This can be due to some activity that it is going to take some time to complete, e.g., IO, allocating memory, and so on, or the process may have put itself to sleep. -
When the activity the thread was waiting for has completed, the kernel will wake up the thread and mark it as runnable . -
We hope that we never get into this state because we are now in a situation where a process (all of its threads) has been asleep for at least 20 seconds. If the system is running out of memory (available memory has dropped below gpgslim ), it will choose processes that have been sleeping for at least 20 seconds. Such a process is a good candidate to page-out because it has been asleep for so long. -
A process that has been deactivated wants to run again; e.g., you have come back from lunch , pressed <cr> on your keyboard, and the kernel needs to send an interrupt to the process. The process will be marked as runnable, but until the kernel can schedule enough pages to be paged-in, the process will not be placed on a run queue. -
The kernel has paged-in enough pages to allow the process to rejoin a run queue. -
This situation occurs when a process is being traced (see ptrace () ) or someone has sent a SIGSTOP or SIGTSTP signal to the process. The process is context switched off the CPU. -
The ptrace() has completed or the process has been sent a SIGCONT signal. The process now wants to run, but it may no longer be the most eligible process to run. The process is marked as runnable . -
The process has now finished whatever it was doing. It has issued an exit() . The kernel will reclaim all the resources used by the process except its entry in the process and thread table. At this point, the process wants its return code to be passed to its parent process that is sent a SIGCHLD signal. The parent may be masking the signal or may be dead. If the parent is dead, the init process has become the parent of this process. The init process will be sent the SIGCHLD signal allowing this process to finish ”be reaped ”and the process table entry returned to the freeproc list. If the parent is still alive but ignoring the SIGCHLD signal, this process will remain a zombie. A zombie can't be killed , because it will never be allowed to run. It is only when a process is going from kernel mode to user mode that it can act on signals. Once the process has been reaped, its entry in the process table is removed and the process disappears . Figure 11-2. Process life cycle. 
NOTES: -
Processes have similar state names associated with them, e.g., SRUN, SZOMB, and so on, as the states associate with threads. While one thread is running, the process will be marked as running . -
Individual threads go through a similar life cycle as processes, including going through the zombie phase. The only subtle difference is the situation where a thread dies and is reaped by the kernel. While other threads are still running, the process will continue to run, obviously. The process isn't reaped until all threads have been reaped beforehand. Ideally, processes and threads will spend most of their time running (see point 3 from Figure 11-2; the state of TSRUNPROC). If not, they are waiting for something to happen that will allow them to continue running. Threads can either relinquish the CPU voluntarily or be forced to relinquish the CPU. Whether forced or voluntary, this is known as a context switch . This is where the current context of the thread, i.e., what it is doing right now, is stored and the next thread is context switched on to the CPU in order to allow it to start executing from where it left off. As far as maximizing processing time, the best time to perform a context switch is when the thread has reached the end of its allotted time on the CPU. It has reached the end of its timeslice . |
