Topic Report:

UNIX Process Management

Jim Heffernan CS511 Spring 11

Abstract
UNIX is a multi-tasking, multi-user operating system. This means that lots of people can run lots of tasks on the same machine, at the same time. Problems can arise if processes are very computationally expensive, and hog the Central Processing Unit (CPU). If this happens, the CPU will be constantly busy, and the system will slow down. Luckily, most tasks tend to spend a lot of time waiting for other information, so this situation does not arise that often. Therefore, UNIX processes must be managed by using a complex set of system functions and capabilities provided by the UNIX OS. Behind the scenes, as we shall see, a tangled web of events are required to insure processes synchronize their actions.

UNIX Process Componentry

Initially, the discussion of what is a process versus what is a program executable must be clearly understood. A program is a static passive module sitting on an area of disk. A process is defined as an instance of a program that is executing or running. A process is anything that is currently active on the computer. For instance, xterm (an X based, terminal emulation program) is a process. A process is made up of components that are used throughout the life of the process. They are: Process ID (pid) -every UNIX process is guaranteed to have a unique numeric identifier called the process ID. It is always a nonegative integer. Segments -virtual address space pieces in the memory layout :

Stack segment -function temporary variables and a return address are saved here each time a function is called. Heap segment -Dynamic Memory Allocation - memory allocation requests ( i.e. malloc(), realloc(), linked lists and so on ).

Data segment -contains global variables that are initialized in the program ( i.e. int maxcount = 99 ; ) outside of any functions and those initialized by the kernel as null pointers or 0 ( i.e. Array Declarations long sum[1000]; ). Text segment -Text Segment is the read-only machine instructions that are executed by the CPU. It is the piece shared by heavyweight processes ( HWPs ).

Thread (LWP) Concept

Some UNIX systems ( i.e. Solaris 2 ) support threads. A thread is a light weight process ( LWP ) that shares, unlike heavyweight processes, data and code sections with peer threads. A thread usually defined as one path of execution through the applications code. A heavyweight process can have one or many threads.

UNIX Process Management and Control

UNIX Process management is largely dependent on the interaction with the services of the kernel. System Calls are the UNIX feature that allows programs to request services of the kernel via system provided function calls.

Process Creation and Deletion

The classic set of system function calls used for UNIX process management are:

fork()
It is used, by an existing process, to create a new process. The new process created by the fork() function is called the child process. The child gets a copy of the parents data space, heap and stack at that time. This is a COPY for the child - the parent and child do not share these portions of memory unless the COW ( copy-on-write ) mechanism is present. If it is, a full copy is not made. If either process tries to modify segment regions, the kernel makes a copy of that piece of memory only. Parent and Child do share the text ( or program instruction ) segment. Once the fork() has been executed, the parent and child go on and continue executing their responsible pieces of code with the instruction following the fork.

exec()
Following a fork() call, the child can call the exec() system function when it wants to execute a different program. Exec() actually replaces the current (child) process (its text, data, heap and stack) with a brand new program from disk that starts executing at its main() function.

wait()
is used when the parent process waits for one or multiple children to terminate before accepting another caller.

exit()
When a process terminates, either abnormally or normally, the parent is notified following the exit by the kernel.

Why and When Use fork() and exec() ?

An obvious question arises due to the nature of the process copy mechanism. Since a COPY of the parent is made for the child, this expensive activity deserves explanation. Specifically, when is fork() frequently used? 1. when a process wants to duplicate itself so that the parent and the child can each execute different sections of code at the same time ( a program that does one or many forks ).

2. when a process wants to execute a different program; it uses the exec() call. User-written Shells and scripts do this quite often.

Process Synchronization
IPC - InterProcess Communication Call Facility
UNIX provides IPC mechanisms for processes to communicate and to synchronize their actions.

Pipes
One of the oldest form of UNIX IPC are Pipes. A pipe is usually an ordinary file implemented to permit byte stream communication between two processes ( parent and child ). Normally, a pipe is created by a process via the pipe system call to implement the pipe. Secondly, that same process in turn calls the fork() system, thus allowing communication between the parent and child process.

Semaphores
A Semaphore is a IPC synchronization tool used to provide access to a single resource among multiple processes. The resource, is usually a segment of code called a processs critical section, which could be in the middle of changing variables, updating a table and so on. The critical section is put under the control of the semaphore, which uses a counter to determine its availability for access to other processors.

Structures:
1. Kernel semid_ds structure The kernel maintains a special internal data structure for each semaphore set which exists within its addressing space. This structure is of type semid_ds, and is defined in linux/sem.h as follows: /* One semid data structure for each set of semaphores in the system. */ struct semid_ds { struct ipc_perm sem_perm; /* permissions .. see ipc.h */ time_t sem_otime; /* last semop time */ time_t sem_ctime; /* last change time */ struct sem sem_base; struct wait_queue *eventn; struct wait_queue *eventz; struct sem_undo undo; ushort sem_nsems; }; /* ptr to first semaphore in array */

/* undo requests on this array */ /* no. of semaphores in array */

2. Kernel sem structure In the semid_ds structure, there exists a pointer to the base of the semaphore array itself. Each array member is of the sem structure type. It is also defined in linux/sem.h:

/* One semaphore structure for each semaphore in the system. */ struct sem { short sempid; /* pid of last operation */ ushort semval; /* current value */ ushort semncnt; /* num procs awaiting increase in semval */ ushort semzcnt; /* num procs awaiting semval = 0 */ };

Process Deadlocks
Process deadlocks are centered around the events of getting and releasing a resource; such as locking region of a file. A deadlock can occur when 2 processes are each waiting for that desired resource that the other has locked. This is why process synchronization ( i.e. semaphores ) routines are made available. They make a process wait for other processes to obtain and release their locks. When a deadlock is detected, the kernel has to choose one process to receive the error return. This can vary based on UNIX system implementations.

The UNIX Kernel -> Executes the Processes

Overall, the kernel uses the system load and its scheduling algorithm to determine which order to run multiple processes. It keeps track of processes via the assigned process PCB (process control block).UNIX mainly uses CPU scheduling ( closely related to the short-term scheduler ) that gives processes small CPU time slices based on the priority algorithm.

Useful Commands for Process Management

Figure 1. below shows a short list of useful process management commands.

Process Management Commands The following are particularly useful commands, for managing processes. kill(1) Send a signal to a process, or terminate a process. ps(1) Display the status of current processes. nice(1) Run a command at low priority. top(1) Display and update information about the top CPU processes. nohup(1) Run a command immune to hangups and quits. sleep(1) Suspend execution for an interval.

Figure 1.
Notably is the kill command. It allows us to send signals** to other processes. It is just an interface to the kill() system function. This command is used to terminate a runaway background process.

** Signals are a UNIX provided capability used to notify a process that some exceptional condition has occurred. A signal is a software interrupt, backed by a routine, that can be generated by a terminal, hardware exception ( i.e. divide by 0 ) and software conditions ( i.e. when a process writes to a pipe after the reader of the pipe has terminated ).

Unix Scheduling Priorities

Unix processes have an associated system nice ( see previous page of Process Management Commands) value which is used by the kernel to determine when it should be scheduled to run. This value can be increased to facilitate processes executing quickly or decreased so that the processes execute slowly and thus do not interfere with other system activities. The process scheduler, which is part of the Unix kernel, keeps the CPU busy by allocating it to the highest priority process. The nice value of a process is used to calculate the scheduling priority of a process. Other factors that are taken into account when calculating the scheduling priority for a process include the recent CPU usage and its process state, for example waiting for I/O or ready to run. Normally, processes inherit the system nice value of their parent process. At system initialization time, the system executes the init process with a system nice value of 20, this is the system default priority. All processes will inherit this priority unless this value is modified with the command nice. The nice value of 0 establishes an extremely high priority, whereas a value of 39 indicates a very low priority on SVR4 derived systems. On BSD derived systems scheduling priorities range from 0 to 127. The higher the value, the lower the priority, and the lower the value, the higher the priority. On systems derived from BSD, the nice command uses the numbers -20 to 20 to indicate the priorities, where 20 is the lowest and -20 is the highest. Any user can lower the priority of their processes, however only superuser can increase the priority of a job.

Examples:
To decrease the priority: # nice -6 mybigjob To increase the priority: # nice --6 mybigjob The nice levels for SVR4 systems are from 0 to 39. The default is 20. To decrease the priority: has been set to 20-6, or 14. To increase the priority: In this example the level has been set to 20+6, or 26. # nice -6 mybigjob In this example the level

# nice +6 mybigjob

UNIX Process Displays

Command-Line Option The ps command allows us to determine information about current processes. The ps -elf command and options will list all your currently-running jobs. An example is shown in Figure 2:

PID TT STAT TIME COMMAND

6799 co IW 6823 co IW 6829 co IW 6830 co S 6836 co I 6837 co I 6841 p0 I 6840 p1 I 6842 p2 S 6847 p2 O

0:01 -csh[rich] (csh) 0:00 /bin/sh /usr/bin/X11/startx 0:00 xinit /usr/lib/X11/xinit/xinitrc 0:12 X :0 0:01 twm 0:01 xclock -geometry 50x50-1+1 0:01 -sh[rich on xterm] (csh) 0:01 -sh[rich on xterm] (csh) 0:01 -sh[rich on login] (csh) 0:00 ps -elf <-heres our pf process! Figure 2.

Here are the meanings of the column titles shown above: COMMAND name of the command that issued the process PID process identification number TT controlling terminal of the process STAT state of the job TIME amount of CPU time the process has acquired so far

Xps - Process State Display for X (runs under Linux

0.99 and higher versions and SunOS 4.x)

Xps is a tool, developed at the Technical University of Chemnitz-Zwickay, Germany, for watching and observing Unix processes ( Figure 3 ). It continuously extractsall processes of the system and displays them in a X Window. The parent-child relationsof the processes will be symbolized by lines connecting a parent with its children. Xps shows you a lot of properties of each process and allows you to send signals to a specified process or a specified process group. Additionally, there is a process state recorder implemented. Using this recorder helps in finding and investigating short term events occurring to UNIX processes.

Figure 3.

Bibliography
Ellzey, Roy S., Computer Systems Software, Science Reasearch Associates, Inc., 1987.

LINUX Documentation Project, LINUX Kernel Hackers Guide,

http://peipa.essex.ac.uk/linux-doc/LDP/khg/khg.html
Stevens, W.R., Advanced Programming in the UNIX Environment, Addision-Wesley Publishing Company, 1992.

UNIX Process Management Commands, Department of Computing, Imperial College, 1995.

http://www.doc.ic.ac.uk/~ard/unix/ProcessManagement.html

Xps - Xlib UNIX Process Analysis Tool, Technical University of Chemnitz-Zwickay, Germany.
http://www.infotech.tu-chemnitz.de/~dako/projects/xps/xps.html