(Latest Revision:
Friday September 10, 2010
)
Chapter Three -- Processes -- Lecture Notes
- 3.0 Chapter Objectives
- introduce the notion of a process
- describe process features - e.g. scheduling, creation, termination,
communication.
- client-server process communication
- 3.1 Process Concept
- Basically a process (aka job or sequential
process) is an executing program.
- "Program" and "process" are very different ideas. A program is like
a recipe. Basically it's a set of written instructions. When a cook
makes a dish following a recipe, the cook is like a process.
- Two or more cooks can be in a kitchen making the same dish, using
(sharing) the same recipe. While they cook, they are not usually
executing the same steps at the same time (although they could be).
Each cook has to keep his or her place in the recipe. Each cook
needs to have his own quantities of ingredients, implements, pots
and pans.
- Like cooks and recipes, it's possible for many processes to execute
the same program concurrently. Like sharing the same recipe,
typically they can share the program code, but they each need to
have certain resources that they use exclusively - for example
separate program counters to keep their places in the program, and
separate runtime stacks to implement their function calls.
- It is very important to understand that only one process can run at
a time on a CPU. If a computer has one CPU, and a user process is
executing, then the OS is suspended - asleep.
- The OS keeps track of each process by representing it with a data
structure. Typically we refer to the "process control block" -- the
PCB. This is a name that represent the sum total of all the
per-process data of which the OS keeps track.
- It is necessary for the OS to store the entire context of the
process in the PCB - everything that would be required to resume the
process if it were deleted from the system.
- Some things in the PCB: the state (new, running, waiting, ready,
terminated); program counter; CPU registers; scheduling information;
memory-management information; accounting information; and I/O
status information.
- On some level an OS can be understood as a queuing system.
Processes make requests for resources like CPU time or I/O, and the
OS puts PCB's in queues (ready queue, device queue, event queue) to
represent processes waiting for resources.
- 3.2 Process Scheduling
- Process control blocks of processes ready to run are kept in a ready
queue (aka run queue).
- There is typically a device queue for each device. PCB's are queued
there if they need to wait for I/O on the device. Typically only
one I/O operation can be in progress at at time on a device. Other
processes have to wait in the queue while the device is busy. If a
process makes a system call requesting I/O, it will be placed in a
device queue. If the device is busy, the process will be placed at
the back of the queue, behind some other process. The process at
the front of the queue is the one waiting for the
currently-executing I/O operation to complete.
- A process that spawns a child process can suspend its execution
until after the child completes its task and terminates. The parent
process executes a wait system call. The result is that the
parent's PCB is placed in an event queue, where it waits for
termination of the child process. The OS places the parent back
into the ready queue after the child exits.
- Batch systems (but not interactive systems) often have a job pool on
secondary memory, consisting of jobs waiting to be accepted for
execution. Such systems have a long-term scheduler, which is the
part of the OS concerned with deciding which of the jobs in the job
pool to load and make executable next.
- The short-term scheduler of an OS is different. It is concerned
with selecting the next job (from the ready queue) to be allowed to
run in the CPU.
- A process that does a lot of I/O and requires relatively little CPU
time (such as a process that mostly interacts with a user) is called
I/O bound.
- A process that does little I/O and spends extended periods of time
using the CPU (such as a processes performing complex calculations)
is called CPU bound.
- If there is a good mix of I/O bound and CPU bound jobs in a system,
it may help assure that there is high average utilization of the I/O
channels and the CPU.
- Many systems have a form of scheduler called a swapper or
medium-term scheduler. This is a part of the OS that copies jobs in
and out of memory, as a means of improving the job mix or assuring
that main memory is not over allocated.
- The context of a process is everything that is required to
keep track of the process -- everything that is needed to maintain
it and keep it going. The role of the PCB is to keep track of the
process context. Context includes things like instruction counter,
process stack, process register values, process memory management
information, open file table, data on all resources allocated to the
process, and so on. Context includes a very extensive amount of
information.
- It is called a context switch when one process leaves the CPU
and a different process resumes execution there.
- 3.3 Operations on Processes
- In many systems the main mechanism for process creation is the
ability of a process to create child processes. In a unix system
typically the booting system creates a few primordial processes, and
all other processes are their descendants. In unix, all user
processes are typically descendants of the "init" process.
- Process creation is something like a function call. A process
creates a child to perform some task. The parent process may pass
parameters and/or resources to the child. Examples of resources are
open files or memory allocations.
- A parent process typically can decide to execute concurrently with a
child process, or it may decide to suspend itself until the child
process completes its work. It can do this via a system call
(wait).
- Typically a parent process "owns" its child processes. For example,
the parent process is able to terminate the child process.
- In unix, the child process begins its life as an exact duplicate of
the parent process, created by a call to the fork() system call.
Often the child calls some form of the exec() system call soon
afterwards, in order to overlay itself with a new program to
execute - a program different from its parent's program.
- In the WIn32 API, a process creates a child process using the
CreateProcess() function call. CreateProcess() also loads whatever
program the new process is supposed to run.
- Typically a process calls some sort of 'exit' system call to request
that the OS 'delete' it -- deallocate its resources. Typically an
operating system acts as an intermediary between a parent process
and the child process for which the parent has waited. The OS wakes
the parent after the child exits, and gives the parent the child's
exit status.
- 3.4 Interprocess Communication
- The modern OS has to provide mechanisms for processes to cooperate.
- Users want to share data.
- Programmers want to write programs that implement cooperating
processes. Why?
- It may be a way for processes to share resources
or information.
- Having more than one process work on a task may be
a way to achieve greater efficiency.
- It may be that one gets a
simpler and more understandable program by designing it as two or
more cooperating processes.
- Cooperating processes need to communicate. The basic means of
communication are
- shared memory and
- passing messages through the kernel via system calls.
- Message passing is relatively easy to implement but requires the
overhead of system calls.
- With shared memory communication, the shared region is typically
established with the help of the OS and thereafter the cooperating
processes use it to communicate without any further OS involvement
or overhead. Process X communicates by writing information in shared
memory, which is then read by process Y. Processes usually have to
employ a synchronization protocol to assure that messages are not
read before they are written, and that two processes don't attempt
to write to the same memory location at the same time.
- The sample producer-consumer code on pages 118-119 gives an example
of a protocol that allows two processes to make use of a shared
array in a synchronized manner, so that there are no errors. The
producer will not overwrite an item that has not yet been consumed.
The consumer will not attempt to copy out an item until the producer
has copied in a 'fresh' item. (The example code is perhaps
deceptively simple-looking.)
- Communication via shared memory is not an option for processes
running on separate CPU's that do not have any main memory in
common. Often message passing is an alternative.
- The protocol for sending messages may involve direct addressing of
senders and/or receivers (send this message to the process with this
id number) or indirect addressing to 'mailboxes' maintained by the
kernel (send/receive a message to/from the mailbox with this id
number)
- The send and receive system calls may either be synchronous
(blocking) or asynchronous (non-blocking).
- Provision may or may not be made for queuing multiple messages
sent to a mailbox. Possibilities are zero buffering capacity,
bounded capacity and unbounded capacity.
- 3.5 Examples of IPC Systems
- Posix Shared Memory
- Use of system call shmget() to create a shared
memory segment
- shmget() returns an integer identifier
- A process that knows the value of the identifier can attach
the segment (with shmat()) and use it.
- There are also system calls for detaching and removing a
a shared-memory segment.
- Mach
- Mach supports message passing.
- Mach employs message mailboxes called ports.
- System calls are implemented by messaging.
- Remote Procedure Call is implemented with messaging.
- msg.send(), msg.receive() and msg,rpc() are primitives.
- The creator is the default owner of the port.
- Rights on ports can be transferred.
- Messages consist of a fixed-length header and a variable-length
list of typed data items.
- Message headers include destination and return port addresses
- A disadvantage of message systems in general is double-copying:
often messages are copied from sender memory to kernel memory,
and then again from kernel memory to recipient memory.
- In the Mach system, memory-mapping techniques are used to avoid
some cases of double-copying. It works on shared-memory
hardware, but not across networks.
- Windows XP
- user processes communicate with subsystems (multiple operating
environments) via a message-passing facility called "local
procedure call" -- LPC.
- Windows XP uses ports like Mach ports.
- User processes establish communication by functioning as clients
of the Windows XP subsystem server.
- Windows XP has two styles of message passing. One involves
double copying and the other uses shared memory to avoid double
copying.
- A callback mechanism supports asynchronous message handling.
- The LPC facility is below and transparent to
the level of the Win32 API.
- 3.6 Communication in Client-Server Systems
- Sockets
- Processes communicating over a network may employ a "socket
interface" - data structures called sockets are used as
endpoints of communication - sort of like telephone handsets
that you can talk into and hear out of.
- There's no analog of a "ring tone" in networking, so servers
have to wait with "their ears to" a socket, until a client
request comes in.
- A socket connection is associated with two numbers - a network
address (usually an IP number) and a port number. The network
address identifies the host computer and the port number
identifies the specific process(es) on the host using the
socket.
- Port numbers below 1024 are reserved for servers offering
well-known services like e-mail transmission, file transfer and
hypertext transfer.
- Socket communication is considered low-level in one sense - it
supports sending and receiving only unstructured streams of
bytes, not structured data types and objects.
- Remote Procedure Call (RPC)
- RPC supports transmission of structured data.
- RPC semantics allow a client to invoke a procedure on a remote
host, connected only via a network, in the same way the client
would call a procedure locally.
- When the client calls a non-local procedure, it results in a
call to the RPC system, which calls a special stub procedure on
the client side. The RPC system passes the function parameters
to the stub.
- The stub contacts a port on a server, marshals parameters, and
sends them in a message to the server.
- A stub on the server side receives the message, invokes the
procedure on the server side, and returns any needed results
back to the client stub.
- The function call made by the client returns normally - just as
if it was a call to a local procedure.
- In marshaling and transmitting parameters, care must be taken
to allow for the fact that the two different hosts may not
represent a data type in the same way.
- Implementations of RPC have to be able to deal with the
possibility that network packets may be lost or duplicated,
because these are common occurrences on computer networks, The
underlying protocol software can manage this by, in essence,
placing serial numbers in each message and requiring
acknowledgment to the sender after messages are received.
- Port numbers of RPC servers may be "hardwired" into client
code, or clients may determine port numbers dynamically by
querying a matchmaker daemon that listens on a well-known
(hardwired) port.
- RPC can be used to Implement remote file service - like NFS.
- Pipes
- Ordinary pipes are an IPC mechanism used for a long time in
unix to allow a pair of processes on the same host to operate
as a producer and consumer. The pipe is a data structure. One
process can write to it, and the other can read from it.
- Unix has a system call pipe() that creates the data structure
and gives access to two small integers called file descriptors,
one used to get access to the writing end of the pipe, and one
to get access to the reading end.
- A unix child process inherits the open files and pipes of its
parent, so parent and child can communicate through an ordinary
pipe. However there's no mechanism other than inheritance for
allowing processes to share an ordinary pipe.
- Windows employs "anonymous pipes" that are similar to the unix
ordinary pipes.
- Ordinary pipes are unidirectional.
- Unix has something called "named pipes" (aka FIFO's) that are
more powerful and feature-rich than ordinary pipes.
- Windows has named pipes too, but they are implemented
differently from the way they are implemented in unix.
- Unix named pipes appear as objects in the file system - if you
go to a directory and do an 'ls', one of the things displayed
might be the name of a FIFO.
- FIFO's allow bidirectional communication, but only in one
direction at a time.
- Two processes have to reside on the same machine in order to
communicate using a FIFO.
- The Windows versions of named pipes are more versatile. They
support full duplex communication (it can flow in both
directions at the same time). Also, processes on different
machines can communicate using a Windows named pipe. Also
Windows named pipes can be used to transmit structured messages,
instead of just a sequence of bytes.