CS 321 Spring 2013 > Lecture Notes for Wednesday, January 30, 2013 |
Note: We will be following the text more closely now. Lecture notes will be limited to short summaries, along with any material that is not in the text.
A process is a program in execution. A program is just code; a process is active. A single program may correspond to more than one process. A program may also correspond to no processes at all, if it is not running.
As noted previously, we also use the term “process” to refer to the OS facility that supports a running program. In practice, this facility may actually support multiple executions.
Processes allow for support of concurrency: logically (if not actually) performing multiple tasks at once. This is done via multitasking: rapidly switching between processes so that they all appear to be executing at the same time.
The OS is responsible for process scheduling: determining when each process runs.
In *ix OSs, new processes are created using fork
.
This is supposed to copy all data of the parent process,
which can be slow.
One solution: vfork
, a system call which does
not make the copy.
The idea is that the new process will do an execve
very soon.
The vfork
call is unfortunately somewhat unsafe,
as modification of data between vfork
and
a subsequent execve
results in undefined behavior.
A more modern solution is to use copy-on-write.
The parent’s data is not copied immediately.
Part of the implementation of the fork
system call
is that the parent’s data is marked so that the
memory manager will
copy any data that is modified between a fork
and a subsequence execve
.
Typically, very little is modified, which makes this
technique very efficient indeed.
On the other hand, if data do get modified,
then copy-on-write means that program behavior is still correct.
Under Windows,
a process is created using the CreateProcess
system call, discussed earlier.
This specifies the executable for the new process,
and so it is roughly equivalent to a fork-exec combination
under *ix OSs.
Processes can be terminated voluntarily or involuntarily, and due to an error or not. This means we have 4 different classes of methods for terminating processes. Examples of each are shown below.
No Error | Error | |
---|---|---|
Voluntary | _exit(0) |
Uncaught exception |
Involuntary | Killed by other process | Fatal error
E.g., segmentation fault due to unauthorized memory access |
There are generally many more processes available to be executed on a processor, than there are processors. Thus, such available processes will be in one of two states. They will be running—currently executing on a processor, or ready— available to be executed, but not currently executing, since some other process is begin executed. The process scheduler switches processes back & forth between these two, giving each available process some time on the processor. Some processes may get more time, because they have higher priority, but all should get some.
There may also be processes that are not available for execution, because they are waiting for something to happen. Such processes are blocked. A running process may become blocked because it is:
read
or write
system call).sleep
system call).waitpid
system call).A process can be suspended by another process, using one kind of signal; we will discuss this futher when we cover interprocess communication.
A blocked process will be moved to a ready state when the event that it is waiting for, happens.
The diagram below illustrates how processes move between states.
Operating systems may divide process states somewhat more finely than the simple running/ready/blocked scheme we have described here.
Introduction to Processes will be continued next time.
ggchappell@alaska.edu