OPERATION ON PROCESS

a.)PROCESS CREATION

Process creation is only the first management action performed by the OS on the process. Since the process will use the resources made available by the OS, further OS activity will typically be needed to manage those resources on behalf of the process. This involves the release of the CPU control from the process to the OS. This release is triggered by various conditions, that can usually be classified as follows:

• Explicit request: the process branches to one of the OS routines (in particular, it could explicitly request to be suspended). Appropriate steps be taken in order maintain through the branch the OS's exclusive on privileged execution mode. Typically such a branch will involve the execution of an appropriate SW interrupt instruction, so that the process yields CPU control to the OS code which provides the needed service. We shall say more about this when talking about ``kernels executing in the context of a process''.
• Hardware interrupt: an hardware event generated outside the CPU that needs be serviced asynchronously. Example: I/O interrupts from DMA or peripherals. Particularly important in this class is the clock (or ``timer'') interrupt, that allows an OS to periodically regain control of the CPU no matter what the current process is doing.
• Exceptional condition originated from ``inside'' the CPU while executing the current task (e.g. attempt to execute unallowed operations, arithmetical errors, etc.)

It is at this point important to analyze the in detail the operations involved in the above CPU release/regain events. From the point of view of an OS managing several processes, in particular, it's important to differentiate between two different scenarios:

• A process is interrupted; some OS service is performed; the process is continued thereafter.
• A process is interrupted; the OS gives control to another process.

Note carefully that the first scenario can be treated similarly to a subroutine call within one process: in order to resume correctly the process after the OS actions it's necessary that only a context switch, i.e. the saving/resuming of the processor state data, be performed before and after the interruption. The second scenario implies a process switch, which is typically a much more time-consuming sequence of operations on the OS side, since it involves the update of process tables and queues, the loading of suspended processes if no ready one are available, etc. It's consequently important for efficiency reasons that the OS be able to identify what services can be provided by a simple context switch (e.g., a memory block allocation in main memory), and which ones it's better to delay, allowing CPU access to another process.

Two interesting consequences derive from the above observation. One, leading to the distinction between processes and threads will be treated later. The second is of interest here, since it leads to understand in greater detail how the OS services are performed from a process's point of view.

b.)PROCESS TERMINATION

Processes terminate either voluntarily through an exit system call or involuntarily as the result of a signal. In either case, process termination causes a status code to be returned to the parent of the terminating process (if the parent still exists). This termination status is returned through the wait4 system call. The wait4 call permits an application to request the status of both stopped and terminated processes. The wait4 request can wait for any direct child of the parent, or it can wait selectively for a single child process or for only its children in a particular process group. Wait4 can also request statistics describing the resource utilization of a terminated child process. Finally, the wait4 interface allows a process to request status codes without blocking.

Within the kernel, a process terminates by calling the exit() routine. The exit() routine first kills off any other threads associated with the process. The termination of other threads is done as follows:

• Any thread entering the kernel from user space will thread_exit() when it traps into the kernel.
• Any thread already in the kernel and attempting to sleep will return immediately with EINTR or EAGAIN, which will force them to back out to user space, freeing resources as they go. When the thread attempts to return to user space, it will instead hit thread_exit().

The exit() routine then cleans up the process's kernel-mode execution state by doing the following:

• Canceling any pending timers
• Releasing virtual-memory resources
• Closing open descriptors
• Handling stopped or traced child processes

With the kernel-mode state reset, the process is then removed from the list of active processes—the allproc list—and is placed on the list of zombie processes pointed to by zombproc. The process state is changed to show that no thread is currently running. The exit() routine then does the following:

• Records the termination status in the p_xstat field of the process structure
• Bundles up a copy of the process's accumulated resource usage (for accounting purposes) and hangs this structure from the p_ru field of the process structure
• Notifies the deceased process's parent

Finally, after the parent has been notified, the cpu_exit() routine frees any machine-dependent process resources and arranges for a final context switch from the process.

The wait4 call works by searching a process's descendant processes for processes that have terminated. If a process in ZOMBIE state is found that matches the wait criterion, the system will copy the termination status from the deceased process. The process entry then is taken off the zombie list and is freed. Note that resources used by children of a process are accumulated only as a result of a wait4 system call. When users are trying to analyze the behavior of a long-running program, they would find it useful to be able to obtain this resource usage information before the termination of a process. Although the information is available inside the kernel and within the context of that program, there is no interface to request it outside that context until process termination.