1 of 65

Unit 2: Process Management

  • Processes
    • Process Concept
    • Process Scheduling
    • Operations on Processes
    • Inter process Communication
  • Threads
    • Overview
    • Multithreading Models
  • CPU Scheduling
    • Basic Concepts
    • Scheduling Criteria
    • Scheduling Algorithms
    • Multiple-Processor Scheduling
  • Linux
    • Process utilities
    • Library Functions
    • System Calls related to process

2 of 65

Process Concept

Process is a program in execution; process execution must progress in sequential fashion.

The process contains Multiple parts

    • The program code, also called text section
    • Current activity including program counter, processor registers.
    • Stack containing temporary data Function parameters, return addresses, local variables etc.
    • Data section containing global variables
    • Heap containing memory dynamically allocated during run time

The structure of a process in memory is

3 of 65

Process Concept

Program is passive entity stored on disk (executable file), process is active

    • Program becomes process when executable file loaded into memory

Execution of program started via GUI mouse clicks, command line entry of its name, etc

One program can be several processes

    • Consider multiple users executing the same program or the same user may invoke many copies of the web browser program. Each of these is a separate process; and although the text sections are equivalent, the data, heap, and stack sections vary.

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 processor

terminated: The process has finished execution

4 of 65

Process State Diagram

Each process is represented in the operating system by a process control block (PCB)-also called a task control block.

A PCB is shown in Figure It contains many pieces of information associated with a specific process, including these:

Process state. The state may be new, ready, running, waiting, halted, and so on.

  • Program counter. The counter indicates the address of the next instruction to be executed for this process.

Process Control Block

5 of 65

Process Control Block

  • CPU registers. The registers include accumulators, index registers, stack pointers, and general-purpose registers, plus any condition-code information. Along with the program counter.

  • Cpu-scheduling information. This information includes a process priority, pointers to scheduling queues, and any other scheduling parameters.

  • Memory-management information. This information may include such information as the value of the base and limit registers, the page tables, or the segment tables, depending on the memory system used by the operating system.

Accounting information. This information includes the amount of CPU and real time used, time limits, account numbers, job or process numbers, and so on.

I/O status information. This information includes the list of I/O devices allocated to the process, a list of open files, and so on.

In brief, the PCB simply serves as the repository for any information that may vary from process to process.

6 of 65

CPU switch from process to process

7 of 65

  • The objective of multiprogramming is to have some process running at all times, to maximize CPU utilization.

  • The objective of time sharing is to switch the CPU among processes so frequently that users can interact with each program while it is running. �
  • To meet these objectives, the process scheduler selects an available process (possibly from a set of several available processes) for program execution on the CPU.

  • For a single-processor system, there will never be more than one running process. If there are more processes, the rest will have to wait until the CPU is free and can be rescheduled

  • Process scheduler selects among available processes for next execution on CPU

  • Maintains scheduling queues of processes
    • 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
    • Processes migrate among the various queues

Process Scheduling

8 of 65

  • A common representation for a process scheduling is a queueing diagram, such as that in Figure.

  • Each rectangular box represents a queue. Two types of queues are present: the ready queue and a set of device queues.

  • The circles represent the resources that serve the queues, and the arrows indicate the flow of processes in the system.

  • A new process is initially put in the ready queue. It waits there until it is selected for execution, or is dispatched. Once the process is allocated the CPU and is executing, one of several events could occur:

Representation of Process Scheduling

9 of 65

Representation of Process Scheduling

  • The process could issue an I/O request and then be placed in an I/O queue.

  • The process could create a new subprocess and wait for the subprocess's termination.

  • The process could be removed forcibly from the CPU, as a result of an interrupt, and be put back in the ready queue.

In the first two cases, the process eventually switches from the waiting state to the ready state and is then put back in the ready queue. A process continues this cycle until it terminates, at which time it is removed from all queues and has its PCB and resources deallocated.

10 of 65

Schedulers

A process migrates among the various scheduling queues throughout its lifetime. The operating system must select, for scheduling purposes, processes from these queues in some fashion. The selection process is carried out by the appropriate scheduler.

There are three types of schedulers 1.Longterm scheduler 2. Short term scheduler 3. Medium term scheduler

1.Long-term scheduler (or job scheduler) – selects processes which are submitted and loads them into memory for execution. Put them in ready queue.

    • Long-term scheduler is invoked infrequently (seconds, minutes) ⇒ (may be slow)
    • The long-term scheduler controls the degree of multiprogramming.

2. Short-term scheduler (or CPU scheduler) selects from among the processes that are ready to execute and allocates the CPU to one of them.

    • Sometimes the only scheduler in a system
    • Short-term scheduler is invoked frequently (milliseconds) ⇒ (must be fast)

11 of 65

Schedulers

  • The primary distinction between these two schedulers lies in frequency of execution.
  • Processes can be described as either:
    • I/O-bound process – spends more time doing I/O than computations, many short CPU bursts
    • CPU-bound process – spends more time doing computations; few very long CPU bursts

3. Medium-term scheduler can be added if degree of multiple programming needs to decrease

    • Remove process from memory, store on disk, bring back in from disk to continue execution: swapping

12 of 65

Schedulers

  • 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 via a context switch

  • Context of a process represented in the PCB
  • Context-switch time is overhead; the system does no useful work while switching
    • The more complex the OS and the PCB 🡺 the longer the context switch
  • Time dependent on hardware support
    • Some hardware provides multiple sets of registers per CPU 🡺 multiple contexts loaded at once

13 of 65

CPU switch from process to process

14 of 65

Operations on Processes

The processes in most systems can execute concurrently, and they may be created and deleted dynamically. Thus, these systems must provide a mechanism for process creation and termination.

A process may create several new processes, via a create-process system call during the course of execution. The creating process is called a parent process, and the new processes are called the children of that process. Each of these new processes may in turn create other processes, forming a tree of processes.

Most operating systems (including UNIX and the Windows family of operating systems) identify processes according to a unique process identifier (or pid), which is typically an integer number.

In general, a process will need certain resources (CPU time, memory, files, 1/0 devices) to accomplish its task. When a process creates a subprocess, that subprocess may be able to obtain its resources directly from the operating system, or it may be constrained to a subset of the resources of the parent process.

The parent may have to partition its resources among its children, or it may be able to share some resources (such as memory or files) among several of its children. Restricting a child process to a subset of the parent's resources prevents any process from overloading the system by creating too many subprocesses.

15 of 65

Resource sharing options

1. Parent and children share all resources

2. Children share subset of parent’s resources

3. Parent and child share no resources

When a process creates a new process, two possibilities exist in terms of execution:

1. The parent continues to execute concurrently with its children.

2. The parent waits until some or all of its children have terminated.

There are also two possibilities in terms of the address space of the new process:

1. The child process is a duplicate of the parent process (it has the same program and data as the parent).

2. The child process has a new 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

16 of 65

C Program Forking Separate Process

17 of 65

Process Termination

A process terminates when it finishes executing its final statement and asks the operating system to delete it by using the exit () system call. At that point, the process may return a status value (typically an integer) to its parent process (via the wait() system call). All the resources of the process-including physical and virtual memory, open files, and I/O buffers-are deallocated by the operating system.

Termination can occur in other circumstances as well. A process can cause the termination of another process using abort() system call , Usually, such a system call can be invoked only by the parent of the process that is to be terminated.

A parent may terminate the execution of one of its children for a variety of reasons, such as these:

• The child has exceeded its usage of some of the resources that it has been allocated.

• The task assigned to the child is no longer required.

• The parent is exiting, and the operating system does not allow a child to

continue if its parent terminates.

18 of 65

Process Termination

Some operating systems do not allow child to exists if its parent has terminated. If a process terminates, then all its children must also be terminated.

    • cascading termination. All children, grandchildren, etc. are terminated.
    • The termination is initiated by the operating system.

The parent process may wait for termination of a child process by using the wait()system call. The call returns status information and the pid of the terminated process

pid = wait(&status);

If no parent waiting (did not invoke wait()) process is a zombie

If parent terminated without invoking wait , process is an orphan

19 of 65

Inter Process Communication

  • A process is independent if it cannot affect or be affected by the other processes executing in the system. Any process that does not share data with any other process is independent.

  • A process is cooperating if it can affect or be affected by the other processes executing in the system. Clearly, any process that shares data with other processes is a cooperating process.

  • There are several reasons for providing an environment that allows process
    • Information sharing. Since several users may be interested in the same piece of information (for instance, a shared file), we must provide an environment to allow concurrent access to such information.
    • Computation speedup. If we want a particular task to run faster, we must break it into subtasks, each of which will be executing in parallel with the others.
    • Modularity. We may want to construct the system in a modular fashion, dividing the system functions into separate processes or threads.
    • Convenience. Even an individual user may work on many tasks at the same time. For instance, a user may be editing, printing, and compiling in parallel.

20 of 65

Interprocess Communication

  • Cooperating processes require an interprocess communication (IPC) mechanism that will allow them to exchange data and Information.
  • Two models of IPC 1. Shared memory 2. Message passing
  • In the shared-memory model, a region of memory that is shared by cooperating processes is established. Processes can then exchange information by reading and writing data to the shared region.
  • In the message passing model, communication takes place by means of messages exchanged between the cooperating processes.
  • Message passing is easier to implement than is shared memory for inter computer communication.
  • Shared memory is faster than message passing, as message-passing systems are typically implemented using system calls and thus require the more time consuming task of kernel intervention.
  • In contrast, in shared-memory systems, system calls are required only to establish shared-memory regions. Once shared memory is established, all accesses are treated as routine memory accesses, and no assistance from the kernel is required.

21 of 65

Communications Models

(a) Message passing. (b) shared memory.

22 of 65

Shared Memory Systems

Interprocess communication using shared memory requires communicating processes to establish a region of shared memory. Typically, a shared-memory region resides in the address space of the process creating the shared-memory segment. Other processes that wish to communicate using this shared-memory segment must attach it to their address space.

Recall that, normally, the operating system tries to prevent one process from accessing another process's memory. Shared memory requires that two or more processes agree to remove this restriction. They can then exchange information by reading and writing data in the shared areas. The form of the data and the location are determined by these processes and are not under the operating system's control.

The processes are also responsible for ensuring that they are not writing to the same location simultaneously.

To illustrate the concept of cooperating processes, let's consider the producer-consumer problem, which is a common paradigm for cooperating processes.

23 of 65

Producer – Consumer Problem

A producer process produces information that is consumed by a consumer process. For example, 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.

The producer-consumer problem also provides a useful metaphor for the client-server paradigm. We generally think of a server as a producer and a client as a consumer. For example, a web server produces (that is, provides) HTML files and images, which are consumed (that is, read) by the client web browser requesting the resource.

One solution to the producer-consumer problem uses shared memory. To allow producer and consumer processes to run concurrently, we must have available a buffer of items that can be filled by the producer and emptied by the consumer. This buffer will reside in a region of memory that is shared by the producer and consumer processes.

24 of 65

Producer – Consumer Problem

A producer can produce one item while the consumer is consuming another item. The producer and consumer must be synchronized, so that the consumer does not try to consume an item that has not yet been produced.

Two types of buffers can be used. The 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.

The bounded buffer assumes a fixed buffer size. In this case, the consumer must wait if the buffer is empty, and the producer must wait if the buffer is full.

The following variables reside in a region of memory shared by the producer and consumer processes:

#define BUFFER_SIZE 10

typedef struct { . . . } item;

item buffer[BUFFER_SIZE];

int in = 0;

int out = 0;

25 of 65

Producer – Consumer Problem

The shared buffer is implemented as a circular array with two logical pointers: in and out. The variable in points to the next free position in the buffer; out points to the first full position in the buffer.

The buffer is empty when in == out;

the buffer is full when ((in + 1) % BUFFERSIZE) == out

The producer process has a local variable nextProduced in which the new item to be produced is stored. The consumer process has a local variable nextConsumed in which the item to be consumed is stored.

26 of 65

Bounded-Buffer – Producer

item next_produced;

while (true) {

/* produce an item in next produced */

while (((in + 1) % BUFFER_SIZE) == out)

; /* do nothing */

buffer[in] = next_produced;

in = (in + 1) % BUFFER_SIZE;

}

Bounded-Buffer – Consumer

item next_consumed;

while (true) {� while (in == out)

; /* do nothing */� next_consumed = buffer[out];

out = (out + 1) % BUFFER_SIZE;�

/* consume the item in next consumed */

}

27 of 65

Inter process Communication – Message Passing Systems

Message passing provides a mechanism to allow processes to communicate and to synchronize their actions without sharing the same address space and is particularly useful in a distributed environment, where the communicating processes may reside on different computers connected by a network. For example, a chat program used on the World Wide Web could be designed so that chat participants communicate with one another by exchanging messages.

A message-passing facility provides at least two operations: send(message) and receive(message).

Messages sent by a process can be of either fixed or variable size.

  1. fixed-sized messages
    • The system-level implementation is straightforward.
    • Makes the task of programming more difficult.

2. variable-sized messages

    • More complex system-level implementation,
    • Programming task becomes simpler.

28 of 65

Message Passing (Cont.)

  • If processes P and Q wish to communicate, they need to:
    • Establish a communication link between them
    • Exchange messages via send/receive

  • There are several methods for logically implementing a link and the send()/receive() operations:

• Direct or indirect communication

• Synchronous or asynchronous communication

• Automatic or explicit buffering

  • Implementation issues:
    • How are links established?
    • Can a link be associated with more than two processes?
    • 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?

29 of 65

Direct Communication

  • In direct communication, each process that wants to communicate must explicitly name the recipient or sender of the communication. In this scheme, the send () and receive ()primitives are defined as:
    • send (P, message) – send a message to process P
    • receive(Q, message) – receive a message from process Q

  • Properties of communication link in this case are
    • A link is established automatically between every pair of processes that want to communicate. The processes need to know only each other's identity to communicate.
    • A link is associated with exactly two processes.
    • Between each pair of processes, there exists exactly one link.
    • The link may be unidirectional, but is usually bi-directional

  • This scheme exhibits symmetry in addressing; that is, both the sender process and the receiver process must name the other to communicate. A variant of this scheme employs asymmetry in addressing. Here, only the sender names the recipient; the recipient is not required to name the sender.

30 of 65

Direct Communication

  • In this scheme, the send () and receive() primitives are defined as follows:
    • send(P, message) -Send a message to process P.
    • receive (id, message) -Receive a message from any process; the variable id is set to the name of the process with which communication has taken place.

  • The disadvantage in both of these schemes (symmetric and asymmetric) is the limited modularity of the resulting process definitions.

  • Changing the identifier of a process may necessitate examining all other process definitions. All references to the old identifier must be found, so that they can be modified to the new identifier.
  • In general, any such hard-coding techniques, here identifiers must be explicitly stated, are less desirable than techniques involving indirection,

31 of 65

Indirect Communication

In indirect communication, the messages are sent to and received from mailboxes, or ports.

A mailbox can be viewed abstractly as an object into which messages can be placed by processes and from which messages can be removed.

Each mailbox has a unique identification. In this scheme, a process can communicate with some other process via a number of different mailboxes. Two processes can communicate only if the processes have a shared mailbox, however. The send() and receive () primitives are defined as follows:

      • send (A, message) -Send a message to mailbox A.
      • receive (A, message) -Receive a message from mailbox A.

Properties of communication link will be

    • Link established only if processes share a common mailbox
    • A link may be associated with many processes
    • Each pair of processes may share several communication links
    • Link may be unidirectional or bi-directional

32 of 65

Indirect Communication

A mailbox may be owned either by a process or by the operating system.

If the mailbox is owned by a process (that is, the mailbox is part of the address space of the process), then we distinguish between the owner (who can only receive messages through this mailbox) and the user (who can only send messages to the mailbox). When a process that owns a mailbox terminates/ the mailbox disappears. Any process that subsequently sends a message to this mailbox must be notified that the mailbox no longer exists.

In contrast/ a mailbox that is owned by the operating system has an existence of its own. It is independent and is not attached to any particular process. The operating system then must provide a mechanism that allows a process to do the following:

    • create a new mailbox (port)
    • send and receive messages through mailbox
    • delete a mailbox

The process that creates a new mailbox is that mailbox's owner by default. Initially, the owner is the only process that can receive messages through this mailbox. However, the ownership and receiving privilege may be passed to other processes through appropriate system calls. Of course/ this provision could result in multiple receivers for each mailbox.

33 of 65

Synchronization

  • Communication between processes takes place through calls to send () and receive () primitives. There are different design options for implementing each primitive. Message passing may be either blocking or non-blocking also known as synchronous and asynchronous.

  • Blocking is considered synchronous
    • Blocking send -- the sender is blocked until the message is received
    • Blocking receive -- the receiver is blocked until a message is available
  • Non-blocking is considered asynchronous
    • Non-blocking send -- the sender sends the message and continue
    • Non-blocking receive -- the receiver receives:
      • A valid message, or
      • Null message
  • Different combinations possible
    • If both send and receive are blocking, we have a rendezvous

34 of 65

Buffering

  • messages exchanged by communicating processes reside in a temporary queue. Basically, such queues can be implemented in three ways:

1. Zero capacity – The queue has a maximum length of zero; thus, the link cannot have any messages waiting in it. In this case, the sender must block until the recipient receives the message.(rendezvous). This is a system with no buffering.

2. Bounded capacity – The queue has finite length n; thus, at most n messages can reside in it. If the queue is not full when a new message is sent, the message is placed in the queue and the sender can continue execution without waiting. If the link is full, the sender must block until space is available in the queue. This is a system with bounded buffering

    • Unbounded capacity – The queues length is potentially infinite; thus, any number of messages can wait in it. The sender never blocks

35 of 65

Threads

A thread is a basic unit of CPU utilization; it comprises a thread ID, a program counter, a register set, and a stack. It shares with other threads belonging to the same process its code section, data section, and other operating-system resources, such as open files and signals. A traditional (or heavyweight) process has a single thread of control. If a process has multiple threads of control, it can perform more than one task at a time.

36 of 65

Motivation

Many software packages that run on modern desktop PCs are multithreaded. A web browser might have one thread display images or text while another thread retrieves data from the network, for example. A word processor may have a thread for displaying graphics, another thread for responding to keystrokes from the user, and a third thread for performing spelling and grammar checking in the background.

A busy web server may have several (perhaps thousands) of clients concurrently accessing it. If the web server ran as a traditional single-threaded process, it would be able to service only one client at a time.

One solution is to have the server run as a single process that accepts requests. When the server receives a request, it creates a separate process to service that request.

Threads also play a vital role in remote procedure call (RPC) systems. Typically, RPC servers are multithreaded. When a server receives a message, it services the message using a separate thread. This allows the server to service several concurrent requests.

Finally, many operating system kernels are now multithreaded; several threads operate in the kernel, and each thread performs a specific task, such as managing devices or interrupt handling.

37 of 65

Benefits

The benefits of multithreaded programming are

1. Responsiveness. Multithreading an interactive application may allow a program to continue running even if part of it is blocked or is performing a lengthy operation, thereby increasing responsiveness to the user. For instance, a multithreaded web browser could still allow user interaction in one thread while an image was being loaded in another thread.

2. Resource sharing. By default, threads share the memory and the resources of the process to which they belong.

3. Economy. Allocating memory and resources for process creation is costly. Because threads share resources of the process to which they belong, it is more economical to create and context-switch threads. In Solaris, for example, creating a process is about 30 times slower than is creating a thread, and context switching is about five times slower.

4. Utilization of multiprocessor architectures. The benefits of multithreading can be greatly increased in a multiprocessor architecture, where threads may be running in parallel on different processors. A single threaded process can only run on one CPU, no matter how many are available. Multithreading on a multi-CPU machine increases concurrency.

38 of 65

Multithreading Models

Support for threads may be provided either at the user level, for user threads, or by the

kernel, for kernel threads.

User threads are supported above the kernel and are managed without kernel support, whereas kernel threads are supported and managed directly by the operating system.

three common ways of establishing a relationship between user threads and kernel threads.

1. Many-to-One Model: The many-to-one model

  1. maps many user-level threads to one kernel thread.
  2. Thread management is done by the thread library in user space, so it is efficient;
  3. the entire process will block if a thread makes a blocking system call.
  4. only one thread can access the kernel at a time, multiple threads are unable to run in parallel on multiprocessors.

39 of 65

Multithreading Models

2. One-to-One Model

  • Each user-level thread maps to kernel thread
  • Creating a user-level thread creates a kernel thread
  • More concurrency than many-to-one
  • Number of threads per process sometimes

restricted due to overhead.

Examples

    • Windows , Linux, Solaris 9 and later

3. Many-to-Many Model

  • Allows many user level threads to be mapped to many kernel threads
  • Allows the operating system to create a sufficient number of kernel threads

Examples

Solaris prior to version 9, Windows with the ThreadFiber package.

40 of 65

CPU Scheduling

  • The objective of multiprogramming is to have some process running at all times, to maximize CPU utilization.

  • A process is executed until it must wait, typically for the completion of some I/O request. In a simple computer system, the CPU then just sits idle. All this waiting time is wasted;

  • With multiprogramming, we try to use this time productively. Several processes are kept in memory at one time. When one process has to wait, the operating system takes the CPU away from that process and gives the CPU to another process. This pattern continues. Every time one process has to wait, another process can take over use of the CPU.

  • Process execution consists of a cycle of CPU execution and I/O wait. Processes alternate between these two states. Process execution begins with a CPU burst. That is followed by an I/O burst, which is followed by another CPU burst, then another I/O burst, and so on.

41 of 65

CPU Scheduler

Whenever the CPU becomes idle, the operating system must select one of the processes in the ready queue to be executed. The selection process is carried out by the short-term scheduler (or CPU scheduler). The scheduler selects a process from the processes in memory that are ready to execute and allocates the CPU to that process.

CPU-scheduling decisions may take place under the following four circumstances:

  1. When a process switches from the running state to the waiting state
  2. When a process switches from the running state to the ready state
  3. When a process switches from the waiting state to the ready state
  4. When a process terminates.

The scheduling can be preemptive or non preemptive

Under non preemptive scheduling, once the CPU has been allocated to a process, the process keeps the CPU until it releases the CPU either by terminating or by switching to the waiting state.

42 of 65

Dispatcher

The dispatcher is the module that gives control of the CPU to the process selected

by the short-term scheduler. This function involves the following:

• Switching context

• Switching to user mode

• Jumping to the proper location in the user program to restart that program

The dispatcher should be as fast as possible, since it is invoked during every process switch. The time it takes for the dispatcher to stop one process and start another running is known as the dispatch latency.

43 of 65

Scheduling Criteria

For choosing which Scheduling algorithm to use in a particular situation, we must consider the following criteria:

CPU utilization. We want to keep the CPU as busy as possible. Conceptually,

CPU utilization can range from 0 to 100 percent.

Throughput. The number of processes that are completed per time unit, called throughput.

Turnaround time. The interval from the time of submission of a process to the time of completion is the turnaround time. Turnaround time is the sum of the periods spent waiting to get into memory, waiting in the ready queue, executing on the CPU, and

doing I/O.

Waiting time. The amount of time that a process spends waiting in the ready queue.

Response time. the time from the submission of a request until the first response is produced. This measure, called response time.

We have to choose a scheduling algorithm to maximize CPU utilization and throughput and to minimize turnaround time, waiting time, and response time.

44 of 65

Scheduling Algorithms

CPU scheduling deals with the problem of deciding which of the processes in the ready queue is to be allocated the CPU. There are many different CPU scheduling algorithms.

  1. First-Come, First-Served Scheduling
  2. Shortest-Jab-First Scheduling
  3. Priority Scheduling
  4. Round-Robin Scheduling
  5. Multilevel Queue Scheduling
  6. Multilevel Feedback-Queue Scheduling

45 of 65

First-Come, First-Served Scheduling

the simplest CPU-scheduling algorithm is the first-come, first-served (FCFS) scheduling algorithm. With this scheme, the process that requests the CPU first is allocated the CPU first.

The implementation of the FCFS policy is easily managed with a FIFO queue. When a process enters the ready queue, its PCB is linked onto the tail of the queue. When the CPU is free, it is allocated to the process at the head of the queue. The running process is then removed from the queue.

The code for FCFS scheduling is simple to write and understand. The average waiting time under the FCFS policy, however, is often quite long.

Consider the following set of processes that arrive at time 0, with the length of the CPU burst given in milliseconds:

Process Burst Time

P1 24

P2 3

P3 3

46 of 65

First-Come, First-Served Scheduling

Suppose that the processes arrive in the order: P1 , P2 , P3 The Gantt Chart for the schedule is:

Turn Around Time

P1 -> Job completion time – job submission time = 24 – 0 = 24

P2 -> 27 – 0 = 27

P3 -> 30 – 0 = 30

Average Turn Around Time = (24+27+30) / 3 = 81/3 = 27 milli sec

Waiting Time

P1 -> Turn Around Time – Burst time = 24 – 24 = 0

P2 - > 27 – 3 = 24

P3 -> 30 – 3 = 27

The average waiting Time = (0+24+27) /3 = 51/3 = 17 milli sec

Response Time

P1 -> First response time – Arrival time = 0 – 0 = 0

P2-> 24 – 0 = 24

P3 -> 27 – 0 = 27

The Average Response Time is = (0+24+27)/3=51/3 = 17 milli sec

47 of 65

First-Come, First-Served Scheduling

If the processes arrive in the order P2, P3, P1,however, the results will be as shown in the following Gantt chart:

.

Turn Around Time

P1 -> Job completion time – job submission time = 30 – 0 = 30

P2 -> 3 – 0 = 3

P3 -> 6 – 0 = 6

Average Turn Around Time = (30+3+6) / 3 = 39/3 = 13 milli sec

Waiting Time

P1 -> Turn Around Time – Burst time = 30 – 24 = 6

P2 - > 3 – 3 = 0

P3 -> 6 – 3 = 3

The average waiting Time = (6+0+3) /3 = 9/3 = 3 milli sec

Response Time

P1 -> First response time – Arrival time = 6 – 0 = 6

P2-> 0 – 0 = 0

P3 -> 3 – 0 = 3

The Average Response Time is = (6+0+3)/3=9/3 = 3 milli sec

48 of 65

First-Come, First-Served Scheduling

The CPU-bound process will get and hold the CPU. During this time, all the other processes will finish their I/O and will move into the ready queue, waiting for the CPU. While the processes wait in the ready queue, the I/O devices are idle.

Eventually, the cpu-bound process finishes its CPU burst and moves to an I/O device. All the I/O-bound processes, which have short CPU bursts, execute quickly and move back to the I/O queues. At this point, the CPU sits idle. The CPU-bound process will then move back to the ready queue and be allocated the CPU. Again, all the I/O processes end up waiting in the ready queue until the CPU-bound process is done. There is a convoy effect as all the other processes wait for the one big process to get off the CPU. This effect results in lower CPU and device utilization than might be possible if the shorter processes were allowed to go first.

The FCFS scheduling algorithm is nonpreemptive. Once the CPU has been allocated to a process, that process keeps the CPU until it releases the CPU, either by terminating or by requesting I/O.

The FCFS algorithm is thus particularly troublesome for time-sharing systems.

49 of 65

Shortest-Jab-First Scheduling

In shortest-job-first (SJF) scheduling algorithm. This algorithm associates with each process the length of the process's next CPU burst. When the CPU is available, it is assigned to the process that has the smallest next CPU burst. If the next CPU bursts of two processes are the same, FCFS scheduling is used to break the tie.

This is the shortest-next-CPU-burst algorithm, because scheduling depends on the length of the next CPU burst of a process, rather than its total length.

As an example of SJF scheduling, consider the following set of processes, with the length of the CPU burst given in milliseconds:

SJF scheduling chart

50 of 65

Shortest-Jab-First Scheduling

Turn Around Time :

P1 -> completion time – arrival time = 9 – 0 = 9

P2 -> 24 – 0 = 24

P3 -> 16 – 0 = 16

P4 -> 3 – 0 = 3

Average Turn Around Time = ( 9+24+16+3)/4 = 52/4 = 13 milli sec

Waiting Time :

P1 -> TAT – BT = 9 – 6 = 3

P2 -> 24 – 8 = 16

P3 -> 16 – 7 = 9

P4 -> 3 – 3 = 0

Average Waiting Time = ( 3+16+9+0)/4 = 28/4 = 7 milli sec

Response Time :

P1 -> starting time – arrival time = 3 – 0 = 3

P2 -> 16 – 0 = 16

P3 -> 9 – 0 = 9

P4 -> 0 – 0 = 0

Average Response Time = ( 3+16+9+0)/4 = 28/4 = 7 milli sec

51 of 65

Shortest-Jab-First Scheduling

The waiting time is 3 milliseconds for process PI, 16 milliseconds for process

P2, 9 milliseconds for process P3, and 0 milliseconds for process P4 . Thus,

average waiting time is (3 + 16 + 9 + 0)/4= 7 milliseconds.

By comparison, if we were using the FCFS scheduling scheme, the average waiting time would be 10.25 milliseconds.

The SJF scheduling algorithm is provably optimal, in that it gives the minimum average waiting time for a given set of processes.

Although the SJF algorithm is optimal, it cam10t be implemented at the level of short-term CPU scheduling. There is no way to know the length of the next CPU burst.

Preemptive version called shortest-remaining-time-first

As an example, consider the following four processes, with the length of the CPU burst given in milliseconds:

52 of 65

Shortest-Jab-First Scheduling

  • Now we add the concepts of varying arrival times and preemption to the analysis

ProcessA arri Arrival TimeT Burst Time

P1 0 8

P2 1 4

P3 2 9

P4 3 5

  • Preemptive SJF Gantt Chart

0th milli sec -> only P1 – 8 ( P1)

1st Milli Sec -> P1 – 7 , P2 – 4 ( P2)

2nd Milli Sec -> P1 – 7 , P2 – 3, P3 – 9 (P2)

3rd Milli Sec - > P1 – 7, P2 – 2, P3-9 , P4 – 5 (P2)

  • Average waiting time = [(10-1)+(1-1)+(17-2)+5-3)]/4 = 26/4 = 6.5 msec

53 of 65

Shortest-Jab-First Scheduling

Turn Around Time :

P1 -> completion time – arrival time = 17 – 0 = 17

P2 -> 5 – 1 = 4

P3 -> 26 – 2 = 24

P4 -> 10 – 3 = 7

Average Turn Around Time = ( 17+4+24+7)/4 = 52/4 = 13 milli sec

Waiting Time :

P1 -> TAT – BT = 17 – 8 = 9

P2 -> 4 – 4 = 0

P3 -> 24 – 9 = 15

P4 -> 7 – 5 = 2

Average Waiting Time = (9+0+15+2)/4 = 26/4 = 6.5 milli sec

Response Time :

P1 -> starting time – arrival time = 0 – 0 = 0

P2 -> 1– 1 = 0

P3 ->17 – 2 = 15

P4 -> 5– 3 = 2

Average Response Time = ( 0+0+15+2)/4 = 17/4 = 4.25 milli sec

54 of 65

Priority Scheduling

A priority is associated with each process,

The CPU is allocated to the process with the highest priority.

Equal-priority processes are scheduled in FCFS order.

An SJF algorithm is simply a priority algorithm where the priority (p) is the inverse of the (predicted) next CPU burst. The larger the CPU burst, the lower the priority, and vice versa.

A major problem with priority scheduling algorithms is indefinite blocking, or starvation. A process that is ready to run but waiting for the CPU can be considered blocked. A priority scheduling algorithm can leave some low priority processes waiting indefinitely.

Problem ≡ Starvation – low priority processes may never execute

Solution ≡ Aging – as time progresses increase the priority of the process

Aging is a technique of gradually increasing the priority of processes that wait in the system for a long time.

55 of 65

Priority Scheduling

ProcessA arri Burst TimeT Priority

P1 10 3

P2 1 1

P3 2 4

P4 1 5

P5 5 2

  • Priority scheduling Gantt Chart

  • Average waiting time = 8.2 msec

56 of 65

Priority Scheduling

Turn Around Time :

P1 -> job completion time – job submission time = 16 - 0=16

P2-> 1 – 0 = 1

P3 -> 18 – 0 = 18

P4 -> 19 – 0 = 19

P5 -> 6 – 0 = 6

 Average Turn Around Time = ( 16+1+18+19+6)/5 = 60/5 = 12 milli sec

 Waiting Time

P1 -> TAT – BT = 16 - 10=6

P2-> 1 – 1 = 0

P3 -> 18 – 2 = 16

P4 -> 19 – 1 = 18

P5 -> 6 – 5 = 1

 Average Waiting Time = (6+0+16+18+1)/5 =41/5 = 8.2 milli sec

 Response Time

P1 -> starting time – Arrival time = 6 - 0=6

P2-> 0 – 0 = 0

P3 -> 16 – 0 = 16

P4 -> 18 – 0 = 18

P5 -> 1 – 0 = 1

 Average Response Time = (6+0+16+18+1)/5 =41/5 = 8.2 milli sec

57 of 65

Priority Scheduling ( Preemptive)

  • Priority scheduling Gantt Chart

1st Milli Sec -> P1-9-3, P2-1-1, ( P2)

2ND Milli Sec -> P1-9-3, P3-2-4 (P1)

3RD Milli Sec -> P1-8-3, P3-2-4, P4-1-3 ( P1)

4TH Milli Sec -> P1-7-3, P3-2-4, P4-1-3, P5-5-2 (P5)

58 of 65

Priority Scheduling

Turn Around Time :

P1 -> job completion time – job submission time = 16 - 0=16

P2-> 2 – 1 = 1

P3 -> 19 –2 = 17

P4 -> 17 – 3 = 14

P5 -> 9 – 4 = 5

 Average Turn Around Time = ( 16+1+17+14+5)/5 = 53/5 = 10.6 milli sec

 Waiting Time

P1 -> TAT – BT = 16 - 10=6

P2-> 1 – 1 = 0

P3 -> 17 – 2 = 15

P4 -> 14 – 1 = 13

P5 -> 5 – 5 = 0

 Average Waiting Time = (6+0+15+13+0)/5 =34/5 = 6.8 milli sec

 Response Time

P1 -> starting time – Arrival time = 0 - 0=0

P2-> 1 – 1 = 0

P3 -> 17 – 2 = 15

P4 -> 16 – 3 = 13

P5 -> 4 – 4 = 0

 Average Response Time = (0+0+15+13+0)/5 =28/5 = 5.6 milli sec

59 of 65

Round Robin Scheduling

The round-robin (RR) scheduling algorithm is designed especially for timesharing

systems. It is similar to FCFS scheduling, but preemption is added to switch between processes.

A small unit of time, called a time quantum or time slice, is defined. A time quantum is generally from 10 to 100 milliseconds.

The ready queue is treated as a circular queue. The CPU scheduler goes around the ready queue, allocating the CPU to each process for a time interval of up to 1

time quantum.

To implement RR scheduling, we keep the ready queue as a FIFO queue of processes. New processes are added to the tail of the ready queue. The CPU scheduler picks the first process from the ready queue, sets a timer to interrupt after 1 time quantum, and dispatches the process.

If the process may have a CPU burst of less than 1 time quantum. In this case, the process itself will release the CPU voluntarily.

Otherwise, if the CPU burst of the currently running process is longer than 1 time quantum, the timer will go off . the process will be put at the tail of the ready queue. The CPU scheduler will then select the next process in the ready queue.

60 of 65

Round Robin Scheduling

Process Burst Time

P1 24

P2 3

P3 3

  • The Gantt chart is: ����
  • Typically, higher average turnaround than SJF, but better response
  • q should be large compared to context switch time
  • q usually 10ms to 100ms, context switch < 10 usec

61 of 65

Round Robin Scheduling

Turn Around Time :

P1 -> job completion time – job submission time = 30 - 0=30

P2-> 7 – 0 = 7

P3 -> 10 –0 = 10

 Average Turn Around Time = ( 30+7+10)/3 = 47/3 = 15.66 milli sec

 Waiting Time

P1 -> TAT – BT = 30 - 24=6

P2-> 7 – 3 = 4

P3 -> 10 – 3 = 7

 Average Waiting Time = (6+4+7)/3 =17/3 = 5.66 milli sec

 Response Time

P1 -> starting time – Arrival time = 0 - 0=0

P2-> 4 – 0 =4

P3 -> 7 – 0 = 7

 Average Response Time = (0+4+7)/3 =11/3 = 3.66 milli sec

62 of 65

Multilevel Queue

  • Ready queue is partitioned into separate queues, eg:
    • foreground (interactive)
    • background (batch)
  • Process permanently in a given queue
  • Each queue has its own scheduling algorithm:
    • foreground – RR
    • background – FCFS
  • Scheduling must be done between the queues:
    • Fixed priority scheduling; (i.e., serve all from foreground then from background). Possibility of starvation.
    • Time slice – each queue gets a certain amount of CPU time which it can schedule amongst its processes; i.e., 80% to foreground in RR
    • 20% to background in FCFS

63 of 65

Multilevel Queue Scheduling

64 of 65

Multilevel Feedback Queue

  • A process can move between the various queues; aging can be implemented this way
  • Multilevel-feedback-queue scheduler defined by the following parameters:
    • number of queues
    • scheduling algorithms for each queue
    • method used to determine when to upgrade a process
    • method used to determine when to demote a process
    • method used to determine which queue a process will enter when that process needs service

65 of 65

Example of Multilevel Feedback Queue

  • Three queues:
    • Q0 – RR with time quantum 8 milliseconds
    • Q1 – RR time quantum 16 milliseconds
    • Q2 – FCFS
  • Scheduling
    • A new job enters queue Q0 which is served FCFS
      • When it gains CPU, job receives 8 milliseconds
      • If it does not finish in 8 milliseconds, job is moved to queue Q1
    • At Q1 job is again served FCFS and receives 16 additional milliseconds
      • If it still does not complete, it is preempted and moved to queue Q2