Processes

Process Concept Process Scheduling Operations on Processes Independent and Cooperating Processes Interprocess Communication Communication in Client-Server Systems

Process Concept
A process is a program in execution (a unit of work)

- an active entity OS processes execute system code and user processes execute user code Types of processes An operating system executes a variety of programs: Process execution must progress in sequential fashion A process includes:
program counter stack data section

Process State
As a process executes, it changes state: New : The process is being created running: Instructions are being executed Waiting: The process is waiting for some event to occur Ready : The process is waiting to be assigned to a CPU terminated: The process has finished execution Only one process can be running on any processor at

any instant

Diagram of Process State

Process Control Block (PCB)

A process is represented in the OS by PCB or

TCB Information associated with each process:

Process state Program counter CPU registers (accumulators, IR, SP, GPR, CCR) CPU scheduling information Memory-management information Accounting information I/O status information

Process Control Block (PCB)

CPU Switch From Process to Process

Process Scheduling Queues

Job queue set of all processes in the system Ready queue set of all processes residing in main

memory, ready and waiting to execute Device queues set of processes waiting for an I/O device Process migrates between the various queues throughout its lifetime Linked list structure is used to build a queue Queuing diagram represents process scheduling Events to occur are:
I/O request Creation of a subprocess An interrupt to remove a process from CPU Time-slice expiry

Ready Queue And Various I/O Device Queues

Representation of Process Scheduling

Schedulers
The job of a scheduler is to select process from

various queues Long-term scheduler (or job scheduler) selects which processes should be brought into the mainmemory Short-term scheduler (or CPU scheduler) selects which process should be executed next and allocates CPU CPU Scheduler:
Is invoked very frequently Must be very fast Process scheduling wastes some time of CPU

 Long-Term Scheduler: Is invoked very infrequently Controls the degree of multiprogramming Can afford to take more time to select a process for execution Must select a good process-mix of I/O-bound and CPUbound processes May be absent or minimal on some systems like timesharing systems Medium-Term Scheduler: Is available in time-sharing systems Removes processes from main-memory so reduces the degree of multiprogramming Carries out swapping-in or swapping-out to improve the process-mix and change in memory requirements

Schedulers

Addition of Medium Term Scheduling

Context Switch
When CPU switches to another process, the system

must save the state of the old process and load the saved state for the new process --- context-switch. Context-switch time is overhead; the system does no useful work while switching. Context-switching speed varies from machine to machine (depends upon memory speed, number of registers to be copied, existence of special instructions). Context-switch times are highly dependent on hardware support. Advanced memory-management techniques are used to shift data to and from memory. Threads are introduced to reduce performance bottleneck because of context switching.

Operations on Processes
Process Creation
Parent process creates children processes, which, in turn

create other processes, forming a tree of processes. Process requires certain resources (i.e CPU time, memory, files, I/O devices) and initialization data (for input) to accomplish its task. Resource sharing
Parent and children share all resources. Children share subset of parents resources. Parent and child share no resources.

Execution possibilities when a process creates a new

process: Parent and children execute concurrently. Parent waits until children terminate.

Process Creation
Address space possibilities of the new processes: Child duplicate of parent. Child has a program loaded into it.

UNIX examples fork system call creates new process. exec system call used after a fork to replace the process memory space with a new program.

The DEC VMS OS creates a new process, loads a

specified program into the address space of the new process. MS Windows NT OS supports both models.

Processes Tree on a UNIX System

Process Termination
Process executes last statement and asks the operating

system to terminate it (exit) .... normal termination.

Output data from child to parent (via wait). Process resources are deallocated by operating system.

Parent may terminate execution of child processes (abort)

.... abnormal termination. Parent may terminate the execution of its children due to following reasons: Child has exceeded allocated resources. Task assigned to child is no longer required. Parent is exiting Operating system does not allow child to continue if its parent

terminates. Cascading termination.

Cooperating Processes
Concurrently executing processes may be independent or

cooperating processes. Characteristics of an Independent Process

Does not share its data with other processes. Execution result is deterministic. Execution is reproducible. Execution can be started/stopped without causing ill-effects.

Characteristics of a Cooperating Process

Shares its data and logical address space (code and data) with

other processes. Execution result is non-deterministic. Execution result cannot be predicted. Execution can be started/stopped causing ill-effects.

Cooperating Processes
Reasons for having cooperating processes are:
Information sharing. Computation speed-up. Modularity. Convenience.

Cooperating processes can communicate with each

other using two schemes: Shared-memory environment. IPC facility.

Synchronization

mechanism is required concurrent execution of cooperating processes.

for

Producer-Consumer Problem (Concept of Cooperating Processes)

Producer process produces information that is consumed by a

consumer process. Examples of producer & consumer are: A print program produces characters that are consumed by the

printer driver. A compiler may produce assembly code, which is consumed by an assembler. The assembler, in turn, may produce object modules, which are consumed by the loader.

Unbounded-buffer places no practical limit on the size of the

buffer - the consumer may have to wait for new items, but the producer can always produce new items. Bounded-buffer assumes that there is a fixed buffer size - the consumer must wait if the buffer is empty and the producer must wait if the buffer is full.

Bounded-Buffer Shared-Memory Solution

Shared variables

#define BUFFER_SIZE 10 Typedef struct { ... } item; item buffer[BUFFER_SIZE]; int in = 0; int out = 0; The shared buffer is implemented by the programmer as a circular array with two printers in & out. Synchronization of producer and consumer processes is required. Solution is correct, but can only use BUFFER_SIZE-1 elements.

Producer-Consumer Problem (Concept of Cooperating Processes)

The buffer may either be provided by the operating system through the

use of an inter process-communication (IPC) facility or by explicitly coded by the application programmer with the use of shared memory.

IN and OUT = 0 . . n-1 buffer = array [0. . n-1] of integer

0 1 2 3 4 5 6 7 8 9

OUT

n=10

IN

full empty

: when IN + 1 = OUT : when OUT = IN full = n-1 buffers

Bounded-Buffer Producer Process /* produce an item in nextProduced variable */ item nextProduced; while (1) { while (((in + 1) % BUFFER_SIZE) == out); /* do nothing */ buffer[in] = nextProduced; in = (in + 1) % BUFFER_SIZE; }

Bounded-Buffer Consumer Process /* Consume the item in nextConsumed variable) item nextConsumed; while (1) { while (in == out); /* do nothing */ nextConsumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; }

Interprocess Communication (IPC)

IPC provides a mechanism for processes to communicate and to

synchronize their actions. IPC is useful in a distributed environment where the communicating processes may reside on different computers connected with a network. IPC is best provided by a message-passing system. In message system, processes communicate with each other without resorting to shared variables. IPC facility provides two operations:
send(message) receive(message)

message size fixed or variable. message size fixed or variable.

If P and Q processes wish to communicate, they need to: establish a communication link between them. exchange messages via send/receive operations. Implementation of communication link: physical (e.g., shared memory, hardware bus or network). logical (e.g., logical properties).

Implementation Questions
How are links established? How many links can there be between every

pair of communicating processes? What is the capacity of a link? Is the size of a message that the link can accommodate fixed or variable? Is a link unidirectional or bi-directional?

Methods for Logical Implementation

Direct or indirect communication Symmetric or asymmetric communication Automatic or explicit buffering Send by copy or send by reference Fixed-sized or variable-sized messages

Direct Communication
Processes must name each other explicitly
send (P, message) send a message to process P. receive(Q, message) receive a message from process Q.

Properties of communication link

Links are established automatically. Between each pair there exists exactly one link. The link may be unidirectional, but is usually bi-directional.

Direct Communication
Symmetric communication Both the sender and the receiver processes have to name each other to communicate. Asymmetric communication Only the sender names the recipient; the recipient is not required to name the sender. send(P, message). Send a message to process P. receive(id, message). Receive a message from any process. The disadvantage in both of these schemes

(symmetric and asymmetric) is the limited modularity of the resulting process definitions.

Indirect Communication
Messages are directed and received from mailboxes (also

referred to as ports).
Each mailbox has a unique id. Processes can communicate only if they share a mailbox.

Primitives are defined as:

send(A, message) send a message to mailbox A. receive(A, message) receive a message from mailbox A.

Properties of communication link in this scheme are:

Link established only if processes share a common mailbox Each pair of processes may share several communication links with

each link corresponding to one mailbox. Link may be unidirectional or bi-directional.

Operations
create a new mailbox. send and receive messages through mailbox. destroy a mailbox.

Indirect Communication
Mailbox sharing
P1, P2 and P3 share mailbox A. P1, sends; P2 and P3 receive. Who gets the message?

Solutions
Allow a link to be associated with at most two processes. Allow only one process at a time to execute a receive

operation.
Allow the system to select arbitrarily the receiver. Sender

is notified who the receiver was.

Direct Communication
Symmetric communication Both the sender and the receiver processes have to name each other to communicate. Asymmetric communication Only the sender names the recipient; the recipient is not required to name the sender. send(P, message). Send a message to process P. receive(id, message). Receive a message from any process. The disadvantage in both of these schemes

(symmetric and asymmetric) is the limited modularity of the resulting process definitions.

Indirect Communication (Mailbox Owned by a Process)

Owner is the process which can receive messages

through this mailbox and user of the mailbox can only send messages to this mailbox.
When owner terminates, the mailbox disappears. No confusion regarding reception of any message as

each mailbox has a unique owner.

Indirect Communication (Mailbox Owned by the OS)

It is independent and cannot be attached to any particular process. The OS allows a process to:
Create a new mailbox (owner). Send and receive messages through the mailbox. Delete a mailbox.

The ownership and receive privileges may be passed to other processes through system calls. Processes can share a mailbox. The OS terminates the mailbox when no more required by any process.

Synchronization
Message passing may be either blocking or non-blocking. Blocking is considered synchronous. Non-blocking is considered asynchronous. send and receive primitives may be either blocking or non

blocking. Blocking send: The sending process is blocked until the message is received by the receiving process or by the mailbox. Nonblocking send: The sending process sends the message and resumes operation. Blocking receive: The receiver blocks until a message is available. Nonblocking receive: The receiver retrieves either a valid message or a null. Rendezvous when both the sender and the receiver are blocking.

Buffering
A link has some capacity for residing a queue of

messages. Zero Capacity:

Queue length = 0; so the link cannot have any messages waiting

on it. Sender must wait until the recipient receives the message. The two processes must be synchronized for message transfer (rendezvous).

Bounded Capacity
Queue length = n; so at most n messages can reside in it. If the queue is not full, the message is placed in the queue (either

it is copied or pointer is kept). Sender can continue execution without waiting . If the queue is full, the sender must wait until the space is available in the queue.

Buffering
Unbounded Capacity
Queue length = infinite; so any number of messages can wait on it.

The sender is never delayed. Bounded and unbounded capacity provides automatic buffering.

Special Cases
Sender is never delayed: New message can overwrite the previous message Advantage: Messages need not to be copied more than once. Disadvantages: Programming task becomes more difficult. Process need to synchronize explicitly. Sender is delayed until it receives a reply: In this scheme, messages are of fixed size. Receiver sends a reply after receiving the message. The reply message overwrites the original message buffer. Can be expanded into a RPC system.

Exception Conditions
An error recovery mechanism (exception conditions) must

resolve various issues in a context of message scheme. Process Termination either a sender or receiver terminates before a message is processed. A receiver process P may wait for a message from a process Q that has terminated. P will be blocked forever. OS either terminates P or notifies P that Q has terminated Process P may send a message to a process Q that has terminated: In the automatic buffering case no harm is done. In the no buffering case P will be blocked forever. OS either terminates P or notifies P that Q has terminated.

Lost Messages
The following methods can be used to deal with a message that is lost

due to a hardware or communication line failure:

The OS is responsible for detecting the event and for resending the

message.
The sending process is responsible for detecting the event and for

retransmitting the message, if it so wants.

The OS is responsible for detecting this event; it then notifies the sending

process that the message has been lost. The sending process can proceed as it wants. Timeouts are used to detect that a message is lost.

Scrambled Messages

The message may be delivered to its destination but was scrambled on the way due to noise in the communication channel. Scrambled message is handled like a lost message. Checksums are used to detect such errors.

Examples Mach OS
Mostly inter process communication is carried out by

messages using mailboxes (ports). System calls are also made by messages. Two special mailboxes created for the task are : Kernel mailbox & Notify mailbox. System calls needed for message transfer are : msgsend, msg-receive & msg-rpc. The port-allocate system call creates a mailbox and up-to 8 messages can be placed in the message queue. Messages are copied into the mailbox and messages are queued in FIFO order. The message consists of: Fixed-length header (length of the message & two mailbox names

i.e. sender & receiver). Variable-length data portion (access rights, task states, memory segments). Each entry in the list has a type, size and value.

 If the Mailbox is full, the sending process has following options: Wait indefinitely until there is a room in the mailbox. Wait for n milliseconds. Do not wait at all. Temporarily cache a message (given to the OS). A port-status system call returns the number of messages in a

mailbox. The receive operation can receive from any mailbox in a mailbox set or a specific (named) mailbox. If no message is waiting to be received, the receiving thread (process) may: Wait indefinitely. Wait for n milliseconds. Do not wait at all.

Mach OS has been designed for distributed systems. Gives poor performance due to double-copy operations (sender to

mailbox & mailbox to receiver). Better performance has been achieved for intra-system messages by mapping the address space containing the senders message into the receivers address space.

Examples Windows 2000 OS

Employes modularity to increase functionality and decreases the time

needed to implement new features.

Provides support for multiple operating environments or subsystems,

with which application programs communicate via a message-passing mechanism.

Message-passing facility is known as Local Procedure Call (LPC) and

communicates between the two processes on the same machine.

Every client (an application program) that calls a subsystem (sever)

needs a communication channel.

Uses two types of ports: Connection ports - named objects visible to all processes; they give

applications a way to set up a communication channel.

Communication ports.

 The communication works as follows:

The client opens a handle to the subsystems connection port object. The client sends a connection request. The server creates two private communication ports and returns the

handle to one of them to the client.

The client and server use the corresponding port handle to send

messages or callbacks and to listen to replies. Message-passing techniques in Windows 2000 over a port are:
Uses the ports message queue as intermediate storage and copies the

message from one process to the other ---- used for smaller messages (up to 256 bytes).
Client passes the larger messages through a section object (or shared

memory).
Server passes the larger messages (replies) through a section object (or

shared memory). A small message along with a pointer is sent in the section object to

avoid the data copying.

The callback mechanism allows client and server to perform

asynchronous message handling.

Communication in Client-Server System (Sockets)

A socket is defined as an endpoint for communication two sockets are required for two processes and use a client server architecture for communication. A socket is made up of an IP address concatenated with a port number. Servers implementing specific services (such as telnet, ftp, and http) listen to well-known ports (a telnet server listens to port 23, an ftp server listens to port 21, and a web (or http) server listens to port 80). For communication using sockets, If a client on host X with IP address 146.86.5.20 wishes to establish a connection with a web server (which is listening on port 80) at address 161.25.19.8; host X may be assigned port 1625 (ports below 1024 are used to implement standard services). All connections consist of a unique pair of sockets. Sockets can be implemented using Java as it provides a much easier interface to sockets and has a rich library for networking utilities. Java provides three different types of sockets:
Connection-oriented (TCP) sockets are implemented with the Socket class. Connectionless (UDP) sockets use the DatagramSocket class.
The Multicast Socket class (allows data to be sent to multiple recipients) which is a

subclass of the DatagramSocket class.

Communication in Client-Server System (Sockets)

Local host mechanism allows the client and server

on the same host to communicate using the TCP/IP protocol. Communication using sockets (although common and efficient) is considered a low-level form of communication between distributed processes because sockets allow only an unstructured stream of bytes to be exchanged between the communicating threads.

Communication Using Sockets

Communication in Client-Server System (RPC)

The RPC has been designed as a way to abstract the

procedure,call mechanism for use between systems with network connections a high level method to provide remote service. The messages exchanged for RPC communication are well structured and are thus no longer just packets of data. RPC provides remote service:
Messages are addressed to an RPC daemon listening to a port on

the remote system, and contain an identifier of the function to execute and the parameters to pass to that function. The function is then executed as requested, and any output is sent back to the requester in a separate message.

Communication in Client-Server System (RPC)

If remote process needs a service, it addresses its

messages to the proper port - One network address on a system can have many ports within that address to differentiate the many network services it supports. Any remote system could obtain the needed information (e.g. the list of current users) by sending an RPC message to port 3027(suppose) on the server; the data would be received in a reply message. The semantics of RPCs allow a client to invoke a procedure on a remote host as it would invoke a procedure locally. The RPC system hides the necessary details allowing the communication to take place by providing a stub (one for each RPC) on the client side.

Communication in Client-Server System (RPC)

When the client invokes a remote procedure: The RPC system calls the appropriate stub, passing it the parameters provided to the remote procedure. The stub locates the port on the server and marshalls the parameters. Parameter marshalling involves packaging the parameters into a form which may be transmitted over a network. The stub then transmits a message to the server using message passing. A similar stub on the server side receives this message and invokes the procedure on the server. If necessary, return values are passed to the client using the same technique.

Communication in Client-Server System (RPC)

Solutions of Operation issues of RPC are:
Many RPC systems define a machine-independent representation of

data such as external data representation (XDR) to resolve data representative issue. The semantics of a call must ensure that RPCs avoid duplication of message issue over unreliable communication links using timestamp mechanism. Approaches to address binding issue of the client and the server port are: The binding information may be predermined in the form of fixed port addresses. Binding can be done dynamically by a rendezvous mechanism an operating system provides a rendezvous (also called a matchmaker) daemon one fixed RPC port.

The RPC scheme is useful in implementing a distributed file

system by implementing a set of RPC daemons and clients.

Execution of a RPC

Communication in Client-Server System (RMI)

Remote Method Invocation (RMI) is a Java mechanism

similar to RPCs. RMI allows a Java program on one machine to invoke a method on a remote object. The remote object may be in a different JVM on the same computer or on a remote host connected by a network. RMI and RPCs differ in two fundamental ways:
RPCs

support procedural programming whereby only remote procedures of functions may be called. RMI is object-based so supports invocation of methods on remote objects. The parameters to remote procedures are ordinary data structures in RPC; with RMI it is possible to pass objects as parameters to remote methods.

Communication in Client-Server System (RMI)

RMI makes it possible for users to develop Java

applications that are distributed across a network. To make remote methods transparent to both the client and the server, RMI implements the remote object using stubs and skeletons.

Communication in Client-Server System (RMI)

A stub is a proxy for the remote object; it resides

with the client. When a client invokes a remote method, this stub for the remote object is called. This client-side stub is responsible for creating a parcel consisting of the name of the method to be invoked on the server and the marshalled parameters for the method. The stub then sends this parcel to the server. The skeleton is responsible for unmarshalling the parameters and invoking the desired method on the server. The skeleton then marshalls the return value (or exception, if any) into a parcel and returns this parcel to the client.

Communication in Client-Server System (RMI)

The client-side stub unmarshalls the return value

and passes it to the client. Rules about the behaviour of parameter passing are:
If

the marshalled parameters are local (or nonremote objects, they are passed by copy using a technique known as object serialization. However, if the parameters are also remote objects, they are passed by reference. If local objects are to be passed as parameters to remote objects, they must implement the interface java.io.Serializable.

Remote Method Invocation

Marshalling Parameters