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.