CS360 Lecture notes -- Intro to Process Control

  • Jian Huang
  • Directory: ~huangj/cs360/notes/Process
  • Lecture notes: http://www.cs.utk.edu/~huangj/cs360/360/notes/Process/lecture.html


    By now, we already know that when a program is run, it then takes the form of a process (an executing instance of a program). Indeed, the OS kernel consists of a bunch of processes as well. Before going into details of how process control is performed, let's first take a look at what makes an OS a multitasking OS.

    The lowest end of OS is basically a sequential program loader with no capability to multitask at all (such as DOS or CP/M). The next level up, an operating system may have cooperative multitasking. In those systems, a process has to voluntarily give up its hold on the processor before the next one can run (a single program error can freeze up the whole machine). Cooperative multitasking is already obsolete, it was merely a transient adaptation to machines lacking hardware for either a periodic clock interrupt or a memory-management unit , or both.

    Unix uses a preemptive multitasking, in which timeslices are allocated by a scheduler which routinely interrupts or pre-empts the running process in order to hand control to the next one. Almost all modern OS supports preemption.

    To make the point that hardware constraints do affect how software can be written, the easiest is to talk about the all-hated Microsoft. In 1981, Microsoft made its historic deal with IBM over the new IBM PC. Bill Gates bought from Seattle Computer Products the QDOS for $50,000. QDOS was written by Tim Paterson of SCP in 6 weeks and was not a real operating system. In fact, QDOS stands for Quick and Dirty Operating System. The reason IBM PC could not afford a real operating system was because a very inexpensive processor, the Intel 8086, was selected as the CPU. In fact, until Intel released its 386 in 1985, IBM PCs never had both a flat address space and a periodic hardware clock interrupt.

    Very ironically, PC broke free of IBM's grip in 1986 because IBM found 386 to be too powerful (it may hurt the price vs. power curve that IBM would like to maintain so that they sell more of their high-end mainframes). Compaq very soon trumped IBM by releasing their 386 PC and then history was cast.


    In Unix, you can make a listing of all the processes that you are currently running with the ps command. Try the following:
    UNIX> ps x
    25919 co IW    0:00 -csh (csh)
    29620 co IW    0:00 xinit
    29621 co S     0:32 X :0
    29645 p0 S     0:01 xclock -geometry 100x100-0-0 -update 60
    29646 p0 S     0:01 spermwatch -newmail xloadimage -onroot /blugreen/homes/plan
    29647 p0 IW    0:00 /bin/sh /blugreen/homes/plank/bin/xyobiff
    29669 p0 S     0:01 twm
    29676 p1 IW    0:00 yobiff plank
      381 p2 S     0:01 -sh (csh)
      713 p2 R     0:00 ps x
      693 p3 S     0:00 vi lecture
    29678 p3 IW    0:00 -sh (csh)
    29684 p4 IW    0:00 -sh (csh)
    29686 p5 IW    0:00 -sh (csh)
    29685 p6 IW    0:00 -sh (csh)

    You should see something like the above. As you should notice, every csh has its own process. The first column of numbers are the "Process ID" numbers, which are called "pid"s. Every process has a non-negative pid, which is unique to that process on that machine while the process is executing.

    Process No. 0, 1 and 2

    There are three special processes with pids 0, 1 and 2. Process 0 is the scheduler (see above), often known as the swapper. It is a kernel process, and no program on disk corresponds to this process (i.e. it is part of the kernel). On some systems, swapper is shown as sched.

    Process 1 is the init program. init is not a kernel process. It is invoked by the kernel at the end of the boot procedure. The program file for init is /sbin/init or /etc/init (on older systems). The process brings up a Unix system after the kernel has been bootstrapped. init reads system-dependent initialization files (/etc/rc*) and brings the system to a certain state. init is a normal process with superuser privilege and never dies.

    On some Unix implementations with virtual memory, process ID 2 is a process supporting paging of the virtual memory. Possible names of this process include pagedaemon or pageout, etc. This is a kernel process.

    In fact, all processes with single digit pid's are all special processes. However, which process is which is more system dependent.

    You can see them using ps aux: (Some machines use different options for ps -- if "ps aux" doesn't work, try "ps -ef").

    UNIX> ps aux | grep root
    root         3  0.1  0.0    0    0 ?        S   Oct 22  4:14 fsflush
    root         0  0.0  0.0    0    0 ?        T   Oct 22  0:17 sched
    root         1  0.0  0.3  848  656 ?        S   Oct 22  0:04 /etc/init -
    root         2  0.0  0.0    0    0 ?        S   Oct 22  0:00 pageout

    getpid, getppid

    Every process has a "parent" process. This is the process that created it. You can get your pid and your parent's pid by using the getpid() and getppid() commands. The program showpid.c is a simple program that prints out its pid, and its parent's pid:

      printf("My pid = %d.  My parent's pid = %d\n", getpid(), getppid());
    Each time you run it, it will show a different pid, but the same parent pid:
    UNIX> showpid
    My pid = 854.  My parent's pid = 381
    UNIX> showpid
    My pid = 855.  My parent's pid = 381
    UNIX> showpid
    My pid = 856.  My parent's pid = 381
    UNIX> showpid
    My pid = 857.  My parent's pid = 381
    UNIX> ps x
      381 p2 S     0:01 -sh (csh)
    As you can see, the csh is the parent of each of these. This is because you typed the commands into the csh, which then created the showpid processes.