Processes
| On path: IPC | 1: Processes • 2: Interprocess Communication • 3: Shared Memory • 4: Files • 5: Unix Signals • 6: Pipes • 7: Sockets • 8: Synchronisation • 9: Synchronisation Barrier • 10: Atomicity • 11: Mutual exclusion • 12: Signal and Wait |
|---|
| On path: Processes | 1: Processes • 2: Context • 3: Process Control Block (PCB) • 4: Multi Threading • 5: Threads • 6: Interprocess Communication • 7: Process Scheduling • 8: Scheduler • 9: Process States • 10: Process Priority |
|---|
| Depends on | Resources • Concepts • User |
|---|
“A process is fundamentally a container that holds all the information needed to run a program.” [Tanenbaum/Bos]
A computer program may be defined as the set of instructions which the computer is to follow to perform some computation. Although you probably already know something about machine instructions, in this course unit we don’t really care about their details; we can think of instructions as lines of source code most of the time.
However, when a program executes it needs more information: for example it will have variables which store values, many of which will be temporary, but important for a while. In practice there are often several attributes associated with this particular, executing copy of a program, such as who ‘owns’ it, which files it is using etc. The executing program, together with this information is typically called a ‘process’.
A typical operating system will allow multiple simultaneous processes. Most will allow the processes to be unaware of each other’s presence, unless the processes specifically want to cooperate. Each process has its own context so, for example, you may be able to run two or more copies of the same program on the same machine at the same time without them interfering with each other.
Most of the process’ context will be kept in memory. A process will have some address space – possibly contiguous addresses, possibly fragmented into several logical segments – which it can use to hold its instructions and variables. This will not encompass all the memory on the machine. The operating system will also hold some private information about the process, typically in a process control block, which may keep track of the various resources ‘owned’ by this process.
Example: if you run a program you don’t specifically attach your name to its data, but the OS may tag it so it can track who is running what.
The process itself will probably not run continuously. Sometimes it may get ‘blocked’ (e.g. waiting for a key-press); if there are many processes running, sometimes it may get ‘pushed aside’; this status is managed by the operating system’s scheduler.
Experiment Try some Unix applications such as
toporps(ps -Ais a good one!) which reveal the currently running processes with some information the OS has kept about them, such as the time they’ve spent being executed.
Unix process structure
In Unix-like systems there is a hierarchy of processes, in that each process has (or once had) a parent process.
At boot time the first process (number 0) ‘forks’ the init process before becoming the idle process. init goes on to create “child” processes. The OS maintains information on the parent (in the process’ PCB). There is a special relationship in that a parent can keep track of its children and children can always enquire who their parent is.
Stop press: you may find
inithas been replaced bysystemdin some systems. The principle is unchanged: check thePID.
A typical example is a shell, which produces a child and (by default) waits for the child to terminate before continuing –
informed by a signal SIGCHLD.
You can display the Unix process tree with the pstree utility; adding a PID as a parameter shows just that branch. (man pstree may reveal more options.)
Orphans
If a parent expires before its children, the children are ‘adopted’ by init. (Daemons are created in
this way.)
Demonstration: there is a little demonstration of this in the example “orphan.c”. Try compiling and running this from a shell, both with and without a terminal ‘
&’ on the command line. Are you confident you can explain the behaviour in each case?
Zombies
Occasionally you may notice “zombie” processes. These are child processes which have terminated but this hasn’t been observed by their (real or adoptive) parent. The OS retains the ‘dead’ process’ details until the parent synchronises with it. Zombies which persist probably indicate a bug of some sort.
Demonstration: there is a little demonstration of this in the example “zombie.c”. Try compiling and running this from a shell. When run the child process terminates first and will remain ‘undead’ for a few seconds. Possibly the easiest way to observe this is to be running
top(or similar) in another window before starting.
- Here’s an article which describes (specifically Linux) processes in quite a lot more detail. It also covers inter-process signals in more detail than we do locally.
| Also refer to: | Operating System Concepts, 10th Edition: Chapter 3, pages 106-154 |
|---|
