Processes in Systems:

• A user can run multiple programs simultaneously on a system (e.g., word processor, web
browser, email client).

• Even systems without multitasking (like embedded devices) require processes for internal
activities (e.g., memory management).

Definition of Processes:

• All user and system activities that need execution are collectively called processes.

Terminology:

• Job and process are terms often used interchangeably.

• Historically, the term "job" was more common, as operating systems focused on job
processing.

• Despite the preference for "process," terms like job scheduling remain widely accepted due
to historical context.

Definition of a Process:

• A process is a program in execution.

• It consists of more than just program code (text section). It includes:

o Program Counter: Tracks the next instruction to execute.

o Registers: Holds current execution context.

o Process Stack: Stores temporary data (e.g., function parameters, return addresses,
local variables).

o Data Section: Contains global variables.

o Heap: Dynamically allocated memory during execution.

Distinction Between Program and Process:

• A program is a passive entity (e.g., an executable file on disk).

• A process is an active entity with associated resources.

Creating a Process:

• A program becomes a process when the executable is loaded into memory.

• Common methods to execute programs:

o Double-clicking the executable file icon.

o Entering the program name in the command line (e.g., prog.exe or java Program).

Multiple Processes:

• Different processes can originate from the same program but function independently (e.g.,
multiple users running a mail program).
 • Processes may share the text section but have separate data, heap, and stack sections.

Processes as Execution Environments:

• Processes can serve as environments for other code (e.g., the Java Virtual Machine (JVM)).

o The JVM runs as a process and executes Java programs within it.

o Example: The command java Program runs the JVM process, which interprets and
executes the Program.class file.

Simulation Concept in JVM:

• The JVM acts as a simulated environment where Java programs run.

• Unlike traditional simulations (targeting different instruction sets), the JVM interprets code
written in Java.

Process State Changes:

• As a process executes, it transitions through different states based on its activity.

Common Process States:

• New: Process is being created.

• Running: Process is actively executing instructions.

• Waiting: Process is waiting for an event (e.g., I/O completion, signal).

• Ready: Process is prepared to execute but is waiting for processor assignment.

• Terminated: Process has completed execution.

State Variations:

• The names and specific states can vary across operating systems, but the concepts are
universal.

• Some operating systems use more granular distinctions for process states.

Processor Limitation:

• At any given time, only one process can run on a single processor.

• Multiple processes may be in the ready or waiting states concurrently.

Process Control Block (PCB):

• A PCB (or Task Control Block) is a data structure in the operating system used to represent
each process.

• It stores information associated with a specific process.

Contents of a PCB:

• Process State: Current state of the process (e.g., new, ready, running, waiting, terminated).

• Program Counter: Address of the next instruction to execute.

 • CPU Registers: Includes accumulators, index registers, stack pointers, general-purpose
registers, and condition codes. Saved during interrupts to allow process resumption.

• CPU-Scheduling Information: Contains process priority, pointers to scheduling queues, and

scheduling parameters.

• Memory-Management Information: Includes data like base and limit registers, page tables,
or segment tables, depending on the memory system.

• Accounting Information: Tracks CPU usage, real-time usage, time limits, account and process
numbers, etc.

• I/O Status Information: Lists allocated I/O devices and open files.

Purpose of the PCB:

• The PCB acts as a repository for all process-specific information.

• It ensures that the operating system can manage and resume processes correctly.

Objectives of Process Scheduling:

• Multiprogramming: Ensures the CPU always has a process to execute, maximizing utilization.

• Time Sharing: Switches the CPU between processes frequently, enabling user interaction
with programs.

Queue Representation:

• A queueing diagram is used to visualize process scheduling.

• Rectangles represent queues (e.g., ready and device queues).

• Circles represent resources serving the queues.

• Arrows show the flow of processes in the system.

Job Queue:

• Contains all processes in the system as they enter.

Ready Queue:

• Holds processes in main memory that are ready and waiting for CPU execution.

• Structure:

o Implemented as a linked list.

o Header contains pointers to the first and last PCBs.

o Each PCB points to the next PCB in the queue.

Device Queues:

• Contains processes waiting for specific I/O devices.

• Each I/O device has its own device queue.

• Processes wait here if the device is busy with another process's I/O request.
Process Flow:

• After entering the system:

o Processes start in the job queue.

o Move to the ready queue when they are ready for execution.

o Transition to device queues if they request I/O and need to wait for resource
availability.

Process Initialization:

• A new process is placed in the ready queue and waits for CPU allocation (dispatch).

Events During Execution:

• While executing, several events can occur:

o I/O Request: Process is moved to an I/O queue to wait for resource availability.

o Child Creation: Process creates a new child process and waits for its termination.

o Interrupt: Process is forcibly removed from the CPU and re-enters the ready queue.

State Transitions:

• In the first two cases, the process moves from the waiting state back to the ready state and
re-enters the ready queue.

• This cycle continues as the process alternates between states.

Process Termination:

• Once the process finishes execution:

o It is removed from all queues.

o Its PCB and allocated resources are deallocated.

Objectives of Multiprogramming and Time Sharing:

• Multiprogramming: Aims to have a process running at all times to maximize CPU utilization.

• Time Sharing: Switches the CPU between processes frequently so that users can interact
with each program while it's running.

Process Scheduling:

• The process scheduler selects an available process from the set of processes for execution
on the CPU.

• In a single-processor system, only one process can run at a time.

o If more processes exist, the rest must wait until the CPU is available for rescheduling.

Process Migration and Scheduling:

• A process migrates between different scheduling queues during its lifecycle.

 • The operating system uses different schedulers to select processes from these queues for
execution.

Schedulers:

• Long-Term Scheduler (Job Scheduler):

o Selects processes from a spool (mass storage) for later execution.

o Loads processes into memory for execution.

• Short-Term Scheduler (CPU Scheduler):

o Selects from the ready queue and allocates the CPU to a process.

o Executes frequently to ensure processes are efficiently allocated CPU time.

Distinction Between Long-Term and Short-Term Schedulers:

• The main difference is in the execution frequency:

o Short-Term Scheduler: Runs often, typically every 100 milliseconds or less, to

allocate CPU time to processes.

o Long-Term Scheduler: Executes less frequently, managing which processes are

loaded into memory.

• Short-term scheduling is fast because it must decide quickly which process gets the CPU. A
long delay (e.g., 10 ms) would waste CPU time by reducing the efficiency of process
execution (e.g., 9% wasted for every 100 ms of process execution)

Execution Frequency of the Long-Term Scheduler:

• Executes much less frequently, possibly with minutes between executions.

• Typically invoked when a process leaves the system to maintain a stable degree of
multiprogramming.

Role of the Long-Term Scheduler:

• Controls the degree of multiprogramming (number of processes in memory).

• Ensures the process creation rate equals the process departure rate to stabilize system load.

Decision-Making and Process Selection:

• The long-term scheduler has more time to make decisions due to infrequent executions.

• Selection focuses on maintaining a balanced mix of:

o I/O-Bound Processes: Spend more time performing I/O than computations.

o CPU-Bound Processes: Spend more time on computations, generating I/O requests

infrequently.

Importance of a Balanced Process Mix:

• A balanced mix ensures efficient resource utilization:

 o If all processes are I/O-bound, the ready queue may remain empty, underutilizing
the CPU.

o If all processes are CPU-bound, the I/O waiting queue may remain empty,
underutilizing I/O devices.

• Optimal performance is achieved when both CPU and I/O devices are utilized effectively.

Absence of Long-Term Scheduler:

• In time-sharing systems like UNIX or Windows, the long-term scheduler may be absent or
minimal.

• All new processes are placed directly into memory for the short-term scheduler to manage.

• System stability depends on:

o Physical limitations, such as the number of terminals.

o Self-regulation by users (e.g., users quitting if performance becomes unacceptable).

Medium-Term Scheduler:

• Introduces an intermediate level of scheduling in some systems.

• Key Function: Temporarily removes processes from memory to:

o Reduce the degree of multiprogramming.

o Improve system performance or balance the process mix.

Swapping:

• A process is swapped out of memory by the medium-term scheduler.

• Later, the process is swapped back in, resuming execution where it left off.

• Benefits of Swapping:

o Frees memory in overcommitted situations.

o Adjusts the process mix to better balance I/O-bound and CPU-bound processes.

Use Case:

• Swapping is especially useful in systems where memory resources are limited, or when
improving system performance requires changes to the active process set.

Interrupts:

• Interrupts force the operating system to:

o Stop the CPU's current task.

o Execute a kernel routine.

• Frequent in general-purpose systems.

State Save and Restore:

 • When an interrupt occurs, the system must save the current context of the running process
to allow resumption later.

• The context includes:

o CPU register values.

o Process state (e.g., ready, waiting).

o Memory management information.

• Saving and restoring the context ensures the process can resume correctly after being
interrupted.

Context Switching:

• The CPU switches from one process to another by:

o Saving the state of the current process in its PCB.

o Restoring the saved state of the next process to be executed.

• This operation is called a context switch.

Overhead of Context Switching:

• Context-switching time is pure overhead because no useful work is performed during the
switch.

• Speed depends on:

o Memory speed.

o Number of registers to copy.

o Availability of special instructions (e.g., single instructions to load/store all registers).

• Typical context-switching time is a few milliseconds.

A context switch is the mechanism to store and restore the state or context of a CPU in

Process Control block so that a process execution can be resumed from the same point at a later
time.

When the scheduler switches the CPU from executing one process to execute another,

the state from the current running process is stored into the process control block. After

this, the state for the process to run next is loaded from its own PCB and used to set

the PC, registers, etc. At that point, the second process can start executing.

Context switches are computationally intensive since register and memory state must

be saved and restored.

Process operations

• A process can create new processes, forming a tree structure.

 • The creating process is called the parent, and the newly created processes are the children.

• Each child process can further create other processes.

Process Identification:

• Most operating systems (e.g., UNIX, Linux, Windows) assign a unique process identifier (pid)
to each process.

• The pid is typically an integer and is used to access a process’s attributes within the kernel.

Linux Process Tree:

• The init process (pid = 1) is the root parent process for all user processes.

• Init creates:

o System processes (e.g., web servers, print servers, ssh servers).

o User processes (e.g., login sessions).

• Example of a process tree:

o kthreadd (child of init) creates kernel-related processes like khelper and pdflush.

o sshd (child of init) manages secure shell (ssh) client connections.

o login manages user logins and can spawn processes like bash.

o Users in bash can create further processes (e.g., ps, emacs).

Example Process Flow:

• A user logs in, initiates the bash shell (e.g., pid 8416).

• From bash, the user starts programs like ps and emacs, each becoming a child process of
bash.

Child Process Resource Management:

• A child process requires resources like CPU time, memory, files, and I/O devices to function.

• Resource allocation:

o The child can obtain resources directly from the operating system.

o Alternatively, it may use a subset of the parent’s resources.

• Parent Resource Partitioning:

o Parents may partition their resources among their children.

o Resources such as memory or files may be shared across multiple children.

• Resource constraints prevent system overload due to excessive child process creation.

Initialization Data for Child Processes:

• Parents can pass initialization data to their children, such as:

o File names (e.g., image.jpg for display processes).

 o Output device information (e.g., terminal or screen).

• Example Workflow:

o A parent process instructs a child to display image.jpg.

o The child opens the file and outputs its content to the terminal or another device.

Resource Passing in Some Operating Systems:

• Some systems allow passing open resources directly to child processes.

• Example:

o A parent passes open file descriptors (e.g., for image.jpg and terminal output).

o The child merely transfers data between the file and the output device, streamlining
the operation.

Execution Possibilities:

• Parent and Child Execute Concurrently:

o The parent process continues running while its child executes independently.

• Parent Waits for Child:

o The parent halts execution and waits for one or more of its children to terminate.

Address-Space Possibilities:

• Child as a Duplicate:

o The child process has the same program and data as the parent.

• Child with a New Program:

o The child process loads an entirely new program into its address space.

Process Creation in UNIX:

• Processes in UNIX are identified by a unique process identifier (pid).

• A new process is created using the fork() system call.

fork() System Call:

• Address Space Duplication:

o The fork() system call creates a child process with an exact copy of the parent’s
address space.

o This enables easy communication between parent and child.

• Execution Continuation:

o Both the parent and the child begin execution at the next instruction after the fork()
call.

• Return Codes:
 o Child Process: fork() returns 0 to the newly created process.

o Parent Process: fork() returns the pid of the child.

Combining fork() and exec():

• After a fork() system call, the new child process is created as an exact copy of the parent.

• Typically, the child process uses the exec() system call to replace its memory space with a
new program.

• The exec() system call:

o Loads a new binary file into the process's memory.

o Overwrites the current memory image of the calling process.

o Begins executing the new program.

o Does not return control unless an error occurs.

Process Behavior:

• The parent process can:

o Create more children.

o Use the wait() system call to pause until a child process terminates.

• The child process can:

o Overwrite its memory space with a new program (using exec()).

o Continue running the same program as the parent (without invoking exec()).

Child Process Characteristics:

• The pid value:

o 0 for the child process.

o Child's pid for the parent process.

• The child process inherits:

o Privileges and scheduling attributes from the parent.

o Certain resources like open files.

Example Workflow (Illustrated in Figures 3.9 and 3.10):

• Child Process:

1. Executes the program /bin/ls (or another binary) via the execlp() system call.

2. Completes execution, implicitly or explicitly calling exit().

• Parent Process:

1. Waits for the child process to terminate using wait().

 2. Resumes and completes its execution, eventually calling exit().

Alternative Scenario:

• The child process does not invoke exec().

• In this case, both parent and child execute the same program instructions concurrently.

• Each process has its own independent copy of data, even though they share the same code
base.

CreateProcess() Overview:

• The CreateProcess() function in the Windows API is used to create a new process.

• Unlike fork(), which creates a child process inheriting the parent's address space:

o CreateProcess() requires loading a specific program into the new process's address
space during its creation.

Parameters of CreateProcess():

• CreateProcess() is more complex than fork() and requires ten parameters:

o Key structures include:

▪ STARTUPINFO: Specifies properties of the new process, such as window size,

standard input/output handles, and more.

▪ PROCESS_INFORMATION: Contains identifiers (e.g., process handle and

thread handle) for the newly created process.

o Other parameters include:

▪ Application name and command-line arguments.

▪ Parent environment or a new environment block.

▪ Flags to control inheritance of handles and other process attributes.

Example: Creating a Child Process:

• The CreateProcess() function can be used to create and launch applications, such as
mspaint.exe.

• Steps:

1. Initialize Structures:

▪ Use ZeroMemory() to allocate memory for STARTUPINFO and

PROCESS_INFORMATION.

2. Specify Application:

▪ Provide the application name or set it to NULL and specify the program in
the command-line parameter.

3. Default Options:
 ▪ Use default values for parameters like environment inheritance and creation
flags.

4. Launch Process:

▪ Pass all parameters to CreateProcess().

Parent-Child Synchronization:

• The parent process can wait for the child to complete using:

o WaitForSingleObject(): Takes the child's process handle (pi.hProcess) and waits until
the child process terminates.

• Once the child process exits, control returns to the parent.

Comparison to UNIX fork():

• fork():

o Creates a duplicate process with the same address space.

o Separate function (exec()) is used to load a new program.

o Simpler function with no parameters.

• CreateProcess():

o Combines process creation and program loading in a single function.

o Requires managing several parameters and structures for process configuration.

Illustration:

• A program using CreateProcess() creates a child process to launch an application (e.g.,

mspaint.exe).

• Example Flow:

1. Parent process initializes data structures.

2. Calls CreateProcess() to start the child process.

3. Waits for the child to terminate using WaitForSingleObject().

4. Resumes its execution after the child completes.

Process Termination: Key Concepts

Normal Termination:

A process terminates by executing its final statement and invoking the exit() system call.

The status value (often an integer) is returned to the parent process via the wait() system call.

After termination, the OS:

Deallocates resources: memory, open files, I/O buffers, etc.

Forced Termination by Parent:

A process can terminate another process using system calls (e.g., TerminateProcess() in Windows).

Typically, only a parent process can terminate its child processes to prevent unauthorized
termination by other users.

Reasons for Parent Terminating a Child:

Resource Overuse:

The child process exceeds its allocated resource limits (e.g., memory or CPU time).

The parent monitors its children to enforce resource constraints.

Task Completion:

The task assigned to the child is no longer needed.

Parent Exit:

In some systems, if a parent process exits, its child processes must also terminate.

This prevents orphaned processes from lingering.

Passing Process Identity:

When a parent creates a child process, the child's process ID (PID) is passed to the parent.

This allows the parent to manage or terminate its children as needed.

Cascading Termination and Process States

1. Cascading Termination:

o Some systems do not allow a child process to continue running if its parent process
terminates.

o When the parent terminates, the operating system automatically terminates all its
child processes.

o This behavior is called cascading termination.

2. Normal Process Termination:

o Processes terminate by calling exit(), which can provide an exit status to the parent
process.

o Example of direct termination:

exit(1);
 o Indirect termination can also occur via a return statement in the main() function.

3. Parent-Child Termination Interaction:

o A parent process can use the wait() system call to:

▪ Obtain the exit status of a child.

▪ Determine which child process has terminated, as wait() returns the child's
PID.

pid_t pid;

int status;

pid = wait(&status);

4. Zombie Processes:

o When a child process terminates, its resources are deallocated, but its entry in the
process table remains until the parent calls wait().

o A terminated process waiting for its parent to call wait() is referred to as a zombie
process.

o Once wait() is called:

▪ The zombie's process table entry is removed.

▪ The PID becomes available for new processes.

5. Orphan Processes:

o If a parent process terminates without invoking wait(), its child processes become
orphans.

o In Linux and UNIX, orphan processes are adopted by the init process (PID 1).

o The init process periodically calls wait() to:

▪ Collect the exit status of orphaned processes.

▪ Release their process table entries and PIDs.

Interprocess Communication (IPC)

Definition:
Processes in an operating system can run independently or cooperatively.

• Independent Processes:

o Do not share data or affect other processes.

o Operate without reliance on other processes.

• Cooperating Processes:

o Share data with and can be affected by other processes.

o Designed to work together for various purposes.

Reasons for Process Cooperation:

1. Information Sharing:

o Multiple users may need concurrent access to shared data (e.g., shared files).

o IPC mechanisms allow safe and efficient data sharing.

2. Computation Speedup:

o Breaking tasks into parallel subtasks can improve performance.

o Effective only with systems having multiple cores or processors.

3. Modularity:

o Systems can be designed with modular components, where each module is a

separate process.

o Improves maintainability and scalability of the system.

4. Convenience:

o Users often perform multiple tasks simultaneously (e.g., editing documents, listening
to music, compiling code).

o Cooperating processes enhance the user experience by enabling multitasking.

Cooperating processes require an IPC mechanism to exchange data and information. Two
fundamental IPC models are:

1. Shared Memory Model

• Definition:

o A region of memory is shared between cooperating processes.

o Processes exchange information by reading and writing to this shared region.

• Advantages:

o Speed: Faster than message passing as it avoids frequent kernel intervention.

o Efficiency: Once established, shared memory behaves like routine memory access.

• Challenges:

o Synchronization: Processes must coordinate access to avoid conflicts (e.g., race

conditions).

o Cache Coherency Issues: On systems with multiple cores, inconsistencies can arise
due to data being stored in multiple caches.

2. Message-Passing Model
 • Definition:

o Processes communicate by exchanging messages.

• Advantages:

o Simplicity: No need for synchronization as each message is sent and received

explicitly.

o Distributed Systems: Easier to implement for systems spread across multiple

physical machines.

o Suitability for Multicore Systems: Avoids cache coherency problems, making it more
efficient on modern multicore processors.

• Challenges:

o Performance: Slower than shared memory due to the overhead of system calls and
kernel intervention.

o Limited Data Exchange: Best suited for small amounts of data.

Models of Interprocess Communication (IPC)

Cooperating processes require an IPC mechanism to exchange data and information. Two
fundamental IPC models are:

1. Shared Memory Model

• Definition:

o A region of memory is shared between cooperating processes.

o Processes exchange information by reading and writing to this shared region.

• Advantages:

o Speed: Faster than message passing as it avoids frequent kernel intervention.

o Efficiency: Once established, shared memory behaves like routine memory access.

• Challenges:

o Synchronization: Processes must coordinate access to avoid conflicts (e.g., race

conditions).

o Cache Coherency Issues: On systems with multiple cores, inconsistencies can arise
due to data being stored in multiple caches.

2. Message-Passing Model

• Definition:

o Processes communicate by exchanging messages.

 • Advantages:

o Simplicity: No need for synchronization as each message is sent and received

explicitly.

o Distributed Systems: Easier to implement for systems spread across multiple

physical machines.

o Suitability for Multicore Systems: Avoids cache coherency problems, making it more
efficient on modern multicore processors.

• Challenges:

o Performance: Slower than shared memory due to the overhead of system calls and
kernel intervention.

o Limited Data Exchange: Best suited for small amounts of data.

Key Comparison

Feature Shared Memory Message Passing

Speed Faster (no kernel intervention) Slower (requires system calls)

Ease of Use Requires synchronization Simpler to implement

Distributed System Suitability Limited Highly suitable

Multicore Performance Cache coherency issues Preferred

Interprocess Communication Using Shared Memory

Establishing Shared Memory

• Creation and Attachment:

o One process creates a shared-memory region in its address space.

o Other processes attach this shared region to their address space to communicate.

• Memory Access Control:

o By default, operating systems prevent processes from accessing each other’s

memory.

o Shared memory bypasses this restriction, allowing direct read/write access.

• Process Responsibility:

o Communicating processes decide the data structure and location in shared memory.

o They must also ensure synchronization to prevent simultaneous writes, which can
lead to data corruption.
Producer–Consumer Problem

Definition:

A common scenario in shared memory IPC, where one process (the producer) generates data that
another process (the consumer) uses.

Examples:

1. Compiler and Assembler:

o A compiler generates assembly code consumed by an assembler.

o The assembler then produces object modules consumed by a loader.

2. Client–Server Paradigm:

o A web server (producer) provides HTML files and images.

o A web browser (consumer) requests and displays these resources.

Key Considerations:

1. Data Consistency:

o Producers and consumers must use proper synchronization techniques (e.g.,

semaphores, mutexes) to avoid race conditions.

2. Buffer Management:

o The producer writes data to a shared buffer, and the consumer reads it.

o A mechanism is needed to ensure the buffer doesn’t overflow (producer too fast) or
underflow (consumer too fast).

Bounded Buffer Solution to the Producer–Consumer Problem

Key Concepts

Buffer Implementation:

A circular array of fixed size (BUFFER_SIZE) is used to hold items produced by the producer and
consumed by the consumer.

Two pointers, in and out, manage the buffer:

in: Points to the next available position for the producer to place an item.

out: Points to the next item for the consumer to retrieve.

Buffer States:

Empty Buffer: When in == out.

Full Buffer: When ((in + 1) % BUFFER_SIZE) == out.

#define BUFFER_SIZE 10 // Size of the buffer

typedef struct {

// Structure representing an item

} item;

item buffer[BUFFER_SIZE]; // Shared buffer

int in = 0; // Next free position

int out = 0; // Next full position

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

Synchronization Techniques

1. Semaphores:

o Use two semaphores:

▪ empty: Tracks the number of empty slots in the buffer.

▪ full: Tracks the number of filled slots.

o A mutex ensures mutual exclusion during buffer modifications.

Producer Process

while (true) {

/* produce an item in next_produced */

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

; /* Wait if the buffer is full */

buffer[in] = next_produced; // Place item in the buffer

in = (in + 1) % BUFFER_SIZE; // Update the in pointer

• next_produced: Local variable holding the newly produced item.

• Buffer Full Condition: ((in + 1) % BUFFER_SIZE) == out

o The producer waits (busy-waits) if the buffer is full.

 • Update in: After placing the item, the in pointer is incremented circularly.

Consumer process

item next_consumed;

while (true) {

while (in == out)

; /* Wait if the buffer is empty */

next_consumed = buffer[out]; // Retrieve item from the buffer

out = (out + 1) % BUFFER_SIZE; // Update the out pointer

/* consume the item in next_consumed */

next_consumed: Local variable holding the retrieved item.

Buffer Empty Condition: in == out

• The consumer waits (busy-waits) if the buffer is empty.

Update out: After retrieving the item, the out pointer is incremented circularly.

Busy Waiting:

• Both the producer and consumer use busy-waiting to handle full and empty conditions,
which is inefficient.

• Solution: Use semaphores or other synchronization mechanisms to replace busy-waiting

(discussed in Chapter 5).

Race Conditions:

• If the producer and consumer access the buffer simultaneously, inconsistencies may occur.

• Solution: Protect critical sections using mutexes or other synchronization primitives.

Key Concepts in Message Passing

Message passing allows processes to communicate and synchronize their actions without sharing
memory. It is essential in distributed systems, where processes may reside on different computers
connected via a network.

Basic Operations in Message Passing

1. Send: send(message)
 2. Receive: receive(message)

Messages can be of:

• Fixed size: Easier system implementation, harder for developers.

• Variable size: Easier for developers, complex system-level implementation.

Communication Link

For processes PPP and QQQ to communicate:

• A communication link must exist.

• The logical implementation of this link determines how messages are exchanged.

Methods for Logical Link Implementation

1. Direct vs. Indirect Communication

• Direct Communication:

o Processes explicitly name each other in send and receive operations.

o Example: send(P, message) or receive(Q, message)

o Properties:

▪ Links are established automatically.

▪ A link exists between exactly two processes.

▪ Bi-directional or uni-directional communication.

• Indirect Communication:

o Messages are sent to and received from mailboxes (or ports).

o Example: send(mailbox, message) or receive(mailbox, message)

o Properties:

▪ Multiple processes can share a mailbox.

▪ Flexibility in process-to-process communication.

▪ Potential for more complex synchronization.

2. Synchronous vs. Asynchronous Communication

• Synchronous (Blocking):

o Sender: Waits until the message is received.

o Receiver: Waits until a message is available.

o Use Case: Real-time systems requiring immediate feedback.

 • Asynchronous (Non-blocking):

o Sender: Sends the message and continues.

o Receiver: Retrieves the message when available.

o Use Case: Systems where processes operate independently.

3. Automatic vs. Explicit Buffering

• Automatic Buffering:

o Messages are stored automatically in a queue.

o The system manages the queue's size and behavior.

• Explicit Buffering:

o Developers define how much space is allocated for messages and how messages are
queued.

o Provides more control but requires careful management to avoid buffer overflows.

Naming in Interprocess Communication

Naming is crucial for processes to identify one another during communication. Two primary
approaches are used: direct communication and indirect communication.

Direct Communication

In direct communication, processes explicitly name each other when sending or receiving messages.
The primitives for this are:

1. send(P, message): Sends a message to process PPP.

2. receive(Q, message): Receives a message from process QQQ.

Properties of Direct Communication:

1. Automatic Link Establishment:

A communication link is automatically established between any two processes that wish to
communicate.

2. Pairwise Link:
Each link is associated with exactly two processes.

3. One Link per Pair:

For any pair of processes, only one communication link exists.

Symmetry in Addressing:

• Both the sender and the receiver must explicitly name the other process for communication.
 • Example:

o PPP: send(Q, message)

o QQQ: receive(P, message)

Asymmetry in Addressing:

• Only the sender specifies the recipient.

• The receiver does not need to know the sender's identity beforehand.

Primitives for asymmetric communication:

1. send(P, message): Sends a message to process PPP.

2. receive(id, message): Receives a message from any process. The variable id captures the
sender's identity.

Example Use Cases:

• Symmetric Communication: Used in tightly coupled systems where both processes are
aware of each other.

• Asymmetric Communication: Useful in systems where processes dynamically interact,

Indirect Communication

Indirect communication introduces a level of indirection by using mailboxes (or ports) for message
exchange. This approach improves modularity compared to direct communication schemes.

How It Works:

• Messages are sent to and received from mailboxes.

• A mailbox is an abstract object that stores messages temporarily.

• Each mailbox is identified by a unique identifier (e.g., an integer in POSIX message queues).

Primitives for Indirect Communication:

1. send(A, message): Sends a message to mailbox AAA.

2. receive(A, message): Receives a message from mailbox AAA.

Properties of Indirect Communication:

1. Link Establishment:
A communication link is established between processes only if they share a common
mailbox.
 2. Multi-process Communication:
A mailbox can facilitate communication between more than two processes.

3. Multiple Links:
Multiple mailboxes can exist between a pair of processes, enabling multiple communication
channels.

When processes P1P1P1, P2P2P2, and P3P3P3 share a common mailbox AAA, and P1P1P1 sends a
message to AAA while P2P2P2 and P3P3P3 execute a receive() operation, the behavior depends on
the message-passing method implemented. The options are as follows:

Methods of Message Reception:

1. Restrict a Link to Two Processes at Most:

o Only two processes (e.g., P1P1P1 and P2P2P2) can communicate via a mailbox at a
time.

o In this case, P2P2P2 would receive the message, and P3P3P3 would be excluded
from accessing the mailbox.

2. Allow Only One Process to Execute receive() at a Time:

o The system ensures mutual exclusion on the receive() operation.

o Whichever process (either P2P2P2 or P3P3P3) gains access first will receive the
message. The other process must wait.

3. System-selects Receiver Arbitrarily:

o The system arbitrarily chooses between P2P2P2 and P3P3P3.

o For instance, it may use an algorithm such as:

▪ Round Robin: Processes alternate in receiving messages.

▪ Priority-based: Assigns a higher priority to one process.

o Only one of P2P2P2 or P3P3P3 will receive the message, and the system may inform
P1P1P1 about which process received it.

Ownership of Mailboxes:

1. Mailbox Owned by a Process:

o The owner process can only receive messages, while other user processes can only
send messages.

o Ownership resolves ambiguity because only the owner can perform receive().

o If the owner process terminates, the mailbox is destroyed, and any further attempts
to send messages result in an error.

2. Mailbox Owned by the Operating System:

 o The mailbox exists independently of any process.

o The system provides mechanisms for processes to:

▪ Create: Set up a new mailbox.

▪ Send/Receive: Communicate through the mailbox.

▪ Delete: Remove the mailbox when it is no longer needed.

Synchronization in Message Passing

The synchronization between processes using message passing depends on whether the send() and
receive() primitives are blocking or nonblocking. These variations influence how processes interact
and whether they must wait for messages to be sent or received.

Types of Message Passing Primitives

1. Blocking Send:

o The sender waits until the message is delivered to the receiver or mailbox.

o Ensures the sender knows when the message has been processed.

o Used in tightly coupled systems where the sender must confirm message delivery.

2. Nonblocking Send:

o The sender immediately resumes its operations after sending the message.

o Allows for greater concurrency, as the sender doesn’t wait for confirmation.

o Suitable for systems prioritizing performance over guaranteed delivery

acknowledgment.

3. Blocking Receive:

o The receiver waits until a message becomes available in the mailbox.

o Ensures the receiver always processes valid messages.

o Useful in scenarios where the receiver depends on continuous message input.

4. Nonblocking Receive:

o The receiver retrieves a message if available; otherwise, it continues execution

(returns null if no message exists).

o Enhances flexibility and responsiveness, especially in event-driven systems.

Combinations of Send and Receive

1. Blocking Send + Blocking Receive (Rendezvous):

o Both sender and receiver wait for each other, creating a synchronized point of
communication.
 o Example: In a producer-consumer system, the producer waits for the consumer to
receive the message, and the consumer waits for the producer to send it.

2. Blocking Send + Nonblocking Receive:

o The sender waits until the message is delivered, but the receiver does not wait for
the message to be available.

o Useful when message delivery is critical but immediate processing by the receiver is
not.

3. Nonblocking Send + Blocking Receive:

o The sender sends the message and continues execution, while the receiver waits for
the message to arrive.

o Useful in systems where the sender can perform other tasks after sending data.

4. Nonblocking Send + Nonblocking Receive:

o Neither the sender nor the receiver waits. Messages are exchanged asynchronously.

o Maximizes concurrency but requires additional logic to handle cases where no

message is available.

Buffering

Whether communication is direct or indirect, messages exchanged by communicating processes

reside in a temporary queue. Basically, such queues can be implemented in three ways:

• 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.

• 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 (either the
message is copied or a pointer to the message is kept), and the sender can continue execution
without waiting. The link’s capacity is finite, however. If the link is full, the sender must block until
space is available in the queue.

• Unbounded capacity. The queue’s length is potentially infinite; thus, any number of messages can
wait in it. The sender never blocks. The zero-capacity case is sometimes referred to as a message
system with no buffering. The other cases are referred to as systems with automatic buffering.

Benefits of Multithreaded Programming

1. Responsiveness

Multithreading enhances the responsiveness of interactive applications, even during lengthy or

blocking operations.

• Example: A user interface remains active and responsive while a time-consuming task, such
as data processing or file loading, runs in a separate thread.

• Advantage: This prevents the application from appearing frozen, improving the user
experience.
2. Resource Sharing

Threads inherently share the resources of their parent process, such as memory and open files.

• Unlike processes, which require explicit mechanisms like shared memory or message
passing, threads can access the same address space seamlessly.

3. Economy

Creating and managing threads is more resource-efficient than processes.

• Process creation involves allocating new memory and resources, which is computationally
expensive.

• Thread creation avoids this by reusing the parent process's resources.

o Context switching between processes is approximately 5 times slower than switching

between threads.

4. Scalability

Multithreading maximizes the use of multiprocessor and multicore systems.

• Parallel Execution: Threads can run on separate cores, enabling true parallelism.

• A single-threaded process is limited to one core, regardless of the number of available

processors.

Multithreading Models

Thread support can exist at both the user level and the kernel level. How user threads interact with
kernel threads depends on the model implemented. The three main models are:

1. Many-to-One Model

This model maps multiple user-level threads to a single kernel thread.

Characteristics:

Thread management occurs in user space using a thread library, making it efficient.

Limitation: If one thread performs a blocking system call, the entire process blocks because only one
kernel thread is available.

Only one thread can access the kernel at a time, preventing parallel execution on multicore systems.

Example:

Early Green threads (used in Solaris and early versions of Java) implemented this model.

2. One-to-One Model
The One-to-One model maps each user thread to a kernel thread.

• Characteristics:

o Allows true concurrency: multiple threads can run in parallel on multiprocessor

systems.

o If one thread makes a blocking system call, other threads can still run.

o Overhead: Creating a user thread requires creating a corresponding kernel thread,

which may lead to performance issues.

o Many systems limit the number of threads to avoid overwhelming system resources.

• Examples:

o Implemented in Linux and the Windows family of operating systems.

3. Many-to-Many Model

The Many-to-Many model maps multiple user threads to a smaller or equal number of kernel
threads.

• Characteristics:

o High concurrency: Developers can create numerous user threads without being
constrained by kernel threads.

o Parallelism: Kernel threads can run user threads concurrently on multiprocessors.

o If one thread performs a blocking system call, the kernel can schedule another
thread to maintain efficiency.

• Variation: Two-Level Model

o Allows a user thread to be explicitly bound to a kernel thread for scenarios where
binding is required.

o Previously used in Solaris (before version 9); Solaris now employs the One-to-One
model.

CPU scheduling is the process of deciding which process will use the CPU at a given time

CPU Scheduling: Preemptive vs. Nonpreemptive

1. Circumstances of CPU Scheduling

CPU scheduling decisions occur under the following conditions:

1. Running → Waiting State

o Happens during an I/O request or when a process invokes a function like wait() for a
child process to terminate.
 2. Running → Ready State

o Occurs due to an interrupt, pausing the currently running process.

3. Waiting → Ready State

o Happens when an I/O operation completes, and the process becomes ready to
execute.

4. Process Termination

o When a process finishes execution, the CPU must select a new process from the
ready queue, if available.

2. Nonpreemptive (Cooperative) Scheduling

• Scheduling occurs only in cases 1 and 4.

• Once a process starts executing, it runs until:

o It moves to the waiting state, or

o It terminates.

3. Preemptive Scheduling

• Scheduling can occur in all four cases.

Criteria for Comparing CPU-Scheduling Algorithms

When selecting a CPU-scheduling algorithm, there are various criterias

1. CPU Utilization

• Goal: Maximize the percentage of time the CPU is actively working.

• Ideal Range:

o 40% for lightly loaded systems.

o 90% for heavily loaded systems.

2. Throughput

• Definition: The number of processes completed per time unit.

• Implication: Higher throughput means the system handles more processes efficiently.

3. Turnaround Time

• Definition: The total time taken for a process to complete from submission to finish.
 • Components:

o Time spent waiting for memory allocation.

o Time in the ready queue.

o Execution time on the CPU.

o Time performing I/O.

• Objective: Minimize turnaround time for better performance.

4. Waiting Time

• Definition: The time a process spends waiting in the ready queue.

• Key Insight:

o CPU scheduling affects only waiting time, not the time for execution or I/O.

• Goal: Reduce waiting time to ensure fair CPU access.

5. Response Time

• Definition: The time from submission of a request to the system until the first response is
generated.

o Response time measures how quickly the system begins processing a request.

Scheduling algorithms

Non preemptive

FCFS

Jobs are executed on first come, first serve basis.

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.

On the negative side, the average waiting time under the FCFS policy is often quite long.

SJF

This is also known as shortest job next

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.

The SJF scheduling algorithm is optimal, giving the minimum average waiting time for a given set of
processes.
The real difficulty with the SJF algorithm is knowing the length of the next CPU request.

The processer should know in advance how much time process will take.

Easy to implement in Batch systems where required CPU time is known in advance.

Impossible to implement in interactive systems where required CPU time is not known.

SJF scheduling is used frequently in long-term scheduling. it cannot be implemented at the level of
short-term CPU scheduling.

One approach to this problem is to try to predictthe length of next CPU burst based on the length to
the previous ones.. The next CPU burst is generally predicted as an exponential average of the
measured lengths of previous CPU bursts.

The SJF algorithm can be either preemptive or nonpreemptive.The next CPU burst of the newly
arrived process may be shorter than what is left of the currently executing process. A preemptive SJF
algorithm will preempt the currently executing process and execute the newly arrived process,
whereas a nonpreemptive SJF algorithm will allow the currently running process to finish its CPU
burst. Preemptive SJF scheduling is sometimes called shortest-remaining-time-first scheduling

Non preemtive SJF

Process Arrival Time (AT) Burst Time (BT)

P0 0 5

P1 1 3

P2 2 8

P3 3 6

| P0 | P1 | P3 | P2 |

0 5 8 14 22

Process AT BT CT TAT WT

P0 0 5 5 5 0

P1 1 3 8 7 4

P3 3 6 14 11 5

P2 2 8 22 20 12

Average WT: 0+4+5+12/4=5.25

Preemptive SJF/SRTF

| P0 | P1 |P0 | P3 | P2 |

0 1 4 8 9 14 22
 Arrival Time Burst Time Completion Time Turnaround Time Waiting Time
Process
(AT) (BT) (CT) (TAT) (WT)

P0 0 5 8 8 3

P1 1 3 4 3 0

P2 2 8 22 20 12

P3 3 6 14 11 5

Priority

A priority is associated with each process, and the CPUis 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.

Priorities are generally indicated by some fixed range of numbers, such as 0 to 7 or 0 to 4,095.

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 lowpriority processes waiting indefinitely. In a heavily loaded computer
system, a steady stream of higher-priority processes can prevent a low-priority process from ever
getting the CPU.

A solution to the problem of indefinite blockage of low-priority processes is aging. Aging involves
gradually increasing the priority of processes that wait in the system for a long time.

Priority scheduling can be either preemptive or nonpreemptive. When a process arrives at the ready
queue, its priority is compared with the priority of the currently running process. A preemptive
priority scheduling algorithm will preempt the CPU if the priority of the newly arrived process is
higher than the priority of the currently running process. A nonpreemptive priority scheduling
algorithm will simply put the new process at the head of the ready queue.

Priority can be decided based on memory requirements, time requirements or any other resource

requirement.

Non preemptive priority scheduling

Process Arrival Time (AT) Burst Time (BT) Priority

P0 0 5 1

P1 1 3 2

P2 2 8 1
Process Arrival Time (AT) Burst Time (BT) Priority

P3 3 6 3

| P0 | P2 | P1 | P3 |

0 5 13 16 22

Arrival Time Burst Time Completion Time Turnaround Time Waiting Time
Process Priority
(AT) (BT) (CT) (TAT) (WT)

P0 0 5 1 5 5 0

P1 1 3 2 16 15 12

P2 2 8 1 13 11 3

P3 3 6 3 22 19 13

Premptive priority scheduling

Process Arrival Time (AT) Burst Time (BT) Priority

P0 0 5 3

P1 1 3 2

P2 2 8 1

P3 3 6 3

| P0 | P1 | P2 | P1 | P0 | P3 |

0 1 2 10 12 16 22

Process AT BT Priority CT TAT (CT - AT) WT (TAT - BT)

P0 0 5 3 16 16 - 0 = 16 16 - 5 = 11

P1 1 3 2 12 12 - 1 = 11 11 - 3 = 8

P2 2 8 1 10 10 - 2 = 8 8 - 8 = 0

P3 3 6 3 22 22 - 3 = 19 19 - 6 = 13

Round Robin algorithm

designed especially for timesharing systems. I

it is similar to FCFS scheduling, but preemption is added to enable the system 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 in length.

The CPU scheduler goes around the ready queue, allocating the CPU to each process for a time
interval of based on time quantum

The CPU scheduler picks the first process from the ready queue, sets a timer to interrupt after
specified time quantum, and dispatches the process.

Once the time quantum is up, A context switch will be executed, and 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.

Once a process is executed for a given time period, it is preempted and other process executes for

a given time period.

Context switching is used to save states of preempted processes.

if the time quantum is extremely large, the RR policy is the same as the FCFS policy. In contrast, if the
time quantum is extremely small .the RR approach can result in a large number of context switches

consider a time quantum of 2 sec

Process Arrival Time (AT) Burst Time (BT)

P0 0 5

P1 1 3

P2 2 8

P3 3 6

| P0 | P1 | P2 | P3 | P0 | P1 | P2 | P3 | P0 | P2 | P3 | P2 |

0 2 4 6 8 10 11 13 15 16 18 20 22

Process AT BT CT TAT WT

P0 0 5 16 16 11

P1 1 3 11 10 7

P2 2 8 22 20 12

P3 3 6 20 17 11

Multi level queue scheduling

Multiple-level queues are not an independent scheduling algorithm. They make use of other existing

algorithms to group and schedule jobs with common characteristics.

A multilevel queue scheduling algorithm partitions the ready queue into several separate queues
The processes are permanently assigned to one queue, generally based on some property of the
process, such as memory size, process priority, or process type

Each queue has its own scheduling algorithm.

an example of a multilevel queue scheduling algorithm with five queues, listed below in order of
priority:

1. System processes 2. Interactive processes 3. Interactive editing processes 4. Batch

processes 5. Student processes

No process in the batch queue, for example, could run unless the queues for system processes,
interactive processes, and interactive editing processes were all empty. If an interactive editing
process entered the ready queue while a batch process was running, the batch process would be
preempted.