Advance Operating Systems-MSCS201-

01/08/2025

Module-1-Multiprocessor Operating Systems: System

Architectures- Structures of OS – OS design issues –
Process synchronisation – Process Scheduling and
Allocation- Memory Management.

SYSTEM ARCHITECTURE:
Types: Symmetric Multiprocessing (SMP), Asymmetric
Multiprocessing (AMP), Uniform Memory Access (UMA), Non-
Uniform Memory Access (NUMA).

Symmetric Multiprocessor

Symmetric Multiprocessing (SMP):

 • Concept: All processors are equal and can run any task. They share a
single copy of the OS and common memory.

• Diagram:

◦ Central shared memory block.

◦ Multiple CPU blocks (CPU1, CPU2, ... CPUT) connected to the shared
memory via a bus/interconnect.

◦ OS kernel residing in shared memory, accessed by all CPUs.

• Key Characteristics: Load balancing, fault tolerance (if one CPU fails,
others can take over), scalability (up to a point).

• All processors can perform any task.

• Processors share a common main memory,

• A single copy of the OS runs across all processors.

• Tasks can be executed by any available processor.

Asymmetric Multiprocessing (AMP):

 • Concept: Processors are assigned specific tasks. One master processor
handles the OS and I/O, while others are slaves executing user processes.

• Diagram:

◦ Master CPU connected to OS kernel, I/O devices, and shared memory.

◦ Slave CPUs connected to shared memory (for data) but communicate

with the Master for OS services.

• Key Characteristics: Simpler to implement than SMP but less flexible

and can have performance bottlenecks if the master CPU is overloaded.

• One master processor controls the system.

• Slave processors execute user code under the master's direction.

• Master handles all OS functions and resource allocation.

• Simpler to implement as it avoids complex synchronisation issues within

the OS kernel.

Uniform Memory Access (UMA):

• In a UMA architecture, all processors have the same access time to all
parts of the main memory.

• This is the defining characteristic of Symmetric Multiprocessor (SMP)

systems.
 • A shared system bus or a crossbar switch connects processors to a
central memory.

• Advantage: Simplicity in programming, as memory access latency is

predictable.

• Disadvantage: The shared bus can become a bottleneck as more

processors are added, limiting scalability.

****Non-Uniform Memory Access (NUMA):****

• In a NUMA architecture, memory access time depends on the memory's

location relative to the processor. The system memory is physically
distributed among processors.

• A processor can access its own local memory much faster than it can
access remote memory (memory connected to another processor).

• Processors are connected via a high-speed interconnection network.

• Advantage: Overcomes the bus bottleneck of UMA, allowing for better

scalability.

• Disadvantage: More complex for the OS and programmers to manage,

as they must consider data locality to achieve good performance. Cache
coherence is also more complex to maintain.
Cache Only Memory Architecture (COMA):

• COMA is a variation of NUMA. In COMA, the local memory for each

processor is essentially a large cache. There is no main memory in the
traditional sense at a fixed "home" location.

• Data migrates to the processor that needs it. If a processor needs data
not in its local cache, the data is found in another processor's cache and
copied over.

• Advantage: Potentially simplifies data locality management since data

automatically migrates.

• Disadvantage: Very complex to implement hardware and coherence

protocols for.

While I cannot directly provide images or diagrams, I can give you a very
detailed text-based breakdown of each module, including concepts that would
typically be illustrated with diagrams and flowcharts. For each topic, I will
explain what a diagram or flowchart would show, helping you visualize it for
your MTech exam preparation.

Since the textbook is from 2001, I will focus on concepts prevalent around that
time, while also pointing out areas where modern OS concepts have evolved.
2. Structures of OS

• Monolithic Kernel:
 ◦ Concept: All OS services (process management, memory
management, file system, device drivers) run in a single address
space, linked statically.

◦ Diagram (Conceptual): A large, single block labeled "Kernel,"

encompassing all OS components. User applications interact with
this block.

◦ Pros: High performance (no context switching overhead between

components).

◦ Cons: Difficult to debug, modify, and extend; a bug in one part can
crash the entire system.

Layered Approach:

• Concept: OS functions are divided into layers, with each layer providing
services to the layer above it and using services from the layer below.

• Diagram (Conceptual): Stack of horizontal layers (e.g., Layer 0:

Hardware, Layer 1: CPU Scheduling, Layer 2: Memory Mgmt, Layer 3: I/O,
Layer 4: User Programs).

• Pros: Easier to debug and develop.

• Cons: Performance overhead due to multiple function calls across layers.

Microkernel:

• Concept: Only essential services (IPC, basic memory management,

process scheduling) reside in the kernel. Other services (file systems,
device drivers) run as user-level processes (servers).

• Diagram (Conceptual): Small "Microkernel" in the center. Around it,

various "servers" (File Server, Device Driver Server, Network Server) in
user space, communicating with the microkernel via message passing.

• Pros: Modularity, extensibility, reliability (failure of a server doesn't

crash the kernel).

• Cons: Performance overhead due to message passing between kernel

and servers.
Features of Microkernel-Based Operating System

• Minimal Core : The kernel only manages basic tasks like CPU
scheduling, memory management, and inter-process communication. All
other services (like device drivers) run in user space, outside the kernel.
• Modularity : System services are separated into independent modules.
This makes it easy to update or replace individual components without
affecting the entire system.
• Stability and Fault Isolation : If a service like a device driver fails, it
won’t crash the whole system. Each service runs independently, so the
core OS remains stable.
• Ease of Maintenance : Since services are independent, fixing bugs or
adding new features doesn’t require major changes to the kernel itself,
making maintenance easier.

3. OS Design Issues
• Concurrency control-ow to manage multiple processors accessing
shared data structures.
• Load Balancing- Distributing processes/threads evenly across
processors to maximize utilization.

• Scalability-How well the OS performs as the number of processors

increases.
• Cache Coherence: Ensuring that all processors have the most up-to-date
view of shared memory, even when data is cached locally.

• Synchronization- Multiple processing of data sync*

• Resource allocation- Efficent allocation of resources
• Reliable &Fault tolerance- How the system continues to function
despite processor failures.

4. Process synchronisation:
Process Synchronization is used in a computer system to ensure
that multiple processes or threads can run concurrently without
interfering with each other.
The main objective of process synchronization is to ensure that multiple
processes access shared resources without interfering with each other
and to prevent the possibility of inconsistent data due to concurrent
access. To achieve this, various synchronization techniques such as
semaphores, monitors and critical sections are used.
In a multi-process system, synchronization is necessary to ensure data
consistency and integrity and to avoid the risk of deadlocks and other
synchronization problems. Process synchronization is an important
aspect of modern operating systems and it plays a crucial role in
ensuring the correct and efficient functioning of multi-process systems.
On the basis of synchronization, processes are categorised as one of the
following two types:

• Independent Process: The execution of one process does not

affect the execution of other processes.
• Cooperative Process: A process that can affect or be affected by
other processes executing in the system.

Process synchronization problem arises in the case of Cooperative

processes also because resources are shared in Cooperative processes.
Process Synchronization
Process Synchronization is the coordination of execution of multiple
processes in a multi-process system to ensure that they access shared
resources in a controlled and predictable manner. It aims to resolve the
problem of race conditions and other synchronization issues in a
concurrent system.

Improper Synchronisation in Inter Process Communication Environment

leads to following problems:

1. Inconsistency: When two or more processes access shared data

at the same time without proper synchronisation. This can lead to
conflicting changes, where one process’s update is overwritten by
another, causing the data to become unreliable and incorrect.
 2. Loss of Data: Loss of data occurs when multiple processes try to
write or modify the same shared resource without coordination. If
one process overwrites the data before another process finishes,
important information can be lost, leading to incomplete or
corrupted data.
3. Deadlock: Lack of proper Synchronization leads to Deadlock which
means that two or more processes get stuck, each waiting for the
other to release a resource. Because none of the processes can
continue, the system becomes unresponsive and none of the
processes can complete their tasks.
4.

Types of Process Synchronization

The two primary type of process Synchronization in an Operating System
are:

1. Competitive: Two or more processes are said to be in Competitive

Synchronization if and only if they compete for the accessibility of a
shared resource.
Lack of Proper Synchronization among Competing process may lead
to either Inconsistency or Data loss.
2. Cooperative: Two or more processes are said to be in Cooperative
Synchronization if and only if they get affected by each other i.e.
execution of one process affects the other process.
Lack of Proper Synchronization among Cooperating process may
lead to Deadlock.
Example:
Let consider a Linux code:
>>ps/grep "chrome"/wc

• ps command produces list of processes running in linux.

• grep command find/count the lines form the output of the ps
command.
• wc command counts how many words are in the output.

Therefore, three processes are created which are ps, grep and wc. grep
takes input from ps and wc takes input from grep.
From this example, we can understand the concept of cooperative
processes, where some processes produce and others consume and thus
work together. This type of problem must be handled by the operating
system, as it is the manager.

Conditions That Require Process Synchronization

1. Critical Section: It is that part of the program where shared

resources are accessed. Only one process can execute the critical
section at a given point of time. If there are no shared resources,
then no need of synchronization mechanisms.
 2. Race Condition: It is a situation wherein processes are trying to
access the critical section and the final result depends on the order
in which they finish their update. Process Synchronization
mechanism need to ensure that instructions are being executed in
a required order only.
3. Pre Emption: Preemption is when the operating system stops a
running process to give the CPU to another process. This allows the
system to make sure that important tasks get enough CPU time.
This is important as mainly issues arise when a process has not
finished its job on shared resource and got preempted. The other
process might end up reading an inconsistent value if process
synchronization is not done.

What is Race Condition?

A race condition is a situation that may occur inside a critical section.
This happens when the result of multiple process/thread execution in the
critical section differs according to the order in which the threads
execute. Race conditions in critical sections can be avoided if the critical
section is treated as an atomic instruction. Also, proper thread
synchronization using locks or atomic variables can prevent race
conditions.
Let us consider the following example.

• There is a shared variable balance with value 100.

• There are two processes deposit(10) and withdraw(10). The deposit
process does balance = balance + 10 and withdraw process does
balance = balance - 10.
 • Suppose these processes run in an interleaved manner. The
deposit() fetches the balance as 100, then gets preempted.
• Now withdraw() get scheduled and makes balance 90.
• Finally deposit is rescheduled and makes the value as 110. This
value is not correct as the balance after both operations should be
100 only

We can not notice that the different segments of two processes running
in different order would give different values of balance.
Critical Section Problem
A critical section is a code segment that can be accessed by only one
process at a time. The critical section contains shared variables that
need to be synchronized to maintain the consistency of data variables.
So the critical section problem means designing a way for cooperative
processes to access shared resources without creating data
inconsistencies.
In the above example, the operations that involve balance variable
should be put in critical sections of both deposit and withdraw.
In the entry section, the process requests for entry in the Critical
Section.
Any solution to the critical section problem must satisfy three
requirements:

• Mutual Exclusion: If a process is executing in its critical section,

then no other process is allowed to execute in the critical section.
 • Progress: If no process is executing in the critical section and
other processes are waiting outside the critical section, then only
those processes that are not executing in their remainder section
can participate in deciding which will enter the critical section next
and the selection cannot be postponed indefinitely.
• Bounded Waiting: A bound must exist on the number of times
that other processes are allowed to enter their critical sections after
a process has made a request to enter its critical section and before
that request is granted.

Critical section Problem - Solutions

Classical IPC Problems
Various classical Inter-Process Communication (IPC) problems include:

• Producer Consumer Problem

• Readers-Writers Problem
• Dining Philosophers Problem

Producer Consumer Problem

The Producer-Consumer Problem is a classic example of process
synchronization. It describes a situation where two types of processes
producers and consumers share a common, limited-size buffer or
storage.
 • Producer: A producer creates or generates data and puts it into
the shared buffer. It continues to produce data as long as there is
space in the buffer.
• Consumer: A consumer takes data from the buffer and uses it. It
continues to consume data as long as there is data available in the
buffer.

The challenge arises because both the producer and the consumer need
to access the same buffer at the same time and if they do not properly
synchronise their actions, issues can occur.
Key Problems in the Producer-Consumer Problem:

1. Buffer Overflow: If the producer tries to add data when the buffer
is full, there will be no space for new data, causing the producer to
be blocked.
2. Buffer Underflow: If the consumer tries to consume data when
the buffer is empty, it has nothing to consume, causing the
consumer to be blocked.

Producer-Consumer Problem - Solution (using Semaphores)

Readers-Writers Problem
The Readers-Writers Problem is a classic synchronization problem where
multiple processes are involved in reading and writing data from a
shared resource. This problem typically involves two types of processes:
 • Readers: These processes only read data from the shared resource
and do not modify it.
• Writers: These processes modify or write data to the shared
resource.

The challenge in the Reader-Writer problem is to allow multiple readers

to access the shared data simultaneously without causing issues.
However, only one writer should be allowed to write at a time and no
reader should be allowed to read while a writer is writing. This ensures
the integrity and consistency of the data.
Readers-Writers Problem - Solution (Readers Preference Solution)
Readers-Writers Problem - Solution (Writers Preference Solution)
Dining Philosophers Problem
The Dining Philosophers Problem is a well-known example that shows
the difficulties of sharing resources and preventing deadlock when
multiple processes are involved. The problem involves a set of
philosophers sitting around a dining table. Each philosopher thinks
deeply, but when they are hungry, they need to eat. However, to eat,
they must pick up two forks from the table, one from the left and one
from the right.
Problem Setup:

• There are five philosophers sitting around a circular table.

• Each philosopher has a plate of food in front of them and a fork to
their left and right.
 • A philosopher needs both forks to eat. If they pick up a fork, they
hold it until they finish eating.
• After eating, they put down both forks and start thinking again.

The problem arises when multiple philosophers try to pick up forks at the
same time, which can lead to a situation where each philosopher holds
one fork but cannot get the second fork, leading to a deadlock.
Additionally, there’s a risk of starvation if some philosophers are
continually denied the opportunity to eat.
Dining Philosophers Problem - Solution (using Semaphores)
Advantages of Process Synchronization

• Ensures Data Consistency and Integrity: Synchronization

ensures that shared resources are accessed in a controlled way,
maintaining data accuracy.
• Avoids Race Conditions: Synchronization prevents unpredictable
outcomes by ensuring that only one process can access a critical
section at a time.
• Prevents Inconsistent Data Due to Concurrent Access:
Synchronization ensures that shared resources are modified by one
process at a time, avoiding data corruption.
• Supports Efficient and Effective Use of Shared Resources:
Synchronization ensures fair and optimal resource allocation,
preventing bottlenecks and improving performance.
Disadvantages of Process Synchronization

• Adds Overhead to the System: Synchronization mechanisms

introduce extra instructions, reducing system efficiency.
• Leads to Performance Degradation: Frequent synchronization
can cause delays and bottlenecks in concurrent processes.
• Increases the Complexity of the System: Managing
synchronization in multi-process systems can complicate design
and maintenance.
• Can Cause Deadlock if Not Implemented Properly: Improper
synchronization can lead to processes being stuck in a waiting
state, causing system freezes.

5. Process Scheduling and Allocation

• Process Scheduling in SMP:

◦ Load Sharing: Distributing processes among available processors.

▪ Techniques:
 ▪ Separate Ready Queues: Each processor has its own queue. Can lead
to imbalance.

▪ Common Ready Queue: All processors take processes from a single

queue. Requires synchronization.

▪ Gang Scheduling: Related threads of a process are scheduled to run

simultaneously on different processors.

◦ Thread Scheduling: Kernel-level threads are scheduled independently.

User-level threads are managed by the application.

A. Processor Allocation: Deciding which processor a process

or thread should run on.

◦ Static Allocation: Process is assigned to a fixed processor.

◦ Dynamic Allocation: Process can migrate between processors.

◦ Affinity Scheduling: Attempts to keep a process on the same processor

as long as possible to benefit from cache locality.

▪ Flowchart: When a process is descheduled, note its last CPU. When

rescheduling, prefer that CPU if available.
6. Memory Management (in Multiprocessor Context)

• Shared Memory Management: How shared memory regions are

protected and accessed.

• Virtual Memory: Each process has its own virtual address space,
mapped to physical memory.

• Paging: Dividing memory into fixed-size blocks (pages and frames).

 ◦ Diagram (Page Table Translation):

▪ CPU generates Virtual Address (Page Number | Offset).

▪ Page Number used as index into Page Table.

▪ Page Table Entry contains Frame Number.

▪ Frame Number + Offset gives Physical Address.

Detailed Explanation:

1. Paging:
The core idea of paging is to break down the address space of a process
(logical address) into smaller, fixed-size blocks called pages. Similarly,
the physical memory is divided into fixed-size blocks called frames.

2. Virtual Address:
The CPU, when accessing memory, generates a virtual address. This
address consists of two parts: the page number (which identifies the
page within the logical address space) and the offset (which identifies
the location within that page).

3. Page Table:
The page table is a data structure that maps virtual pages to physical
frames. Each entry in the page table corresponds to a page and contains
the frame number where that page is located in physical memory.

4. Address Translation:
When the CPU generates a virtual address, the memory management
unit (MMU) uses the page number to index into the page table. The
corresponding entry in the page table provides the frame number.
5. Physical Address:
The physical address is then constructed by combining the frame
number (obtained from the page table) with the offset from the original
virtual address. This effectively translates the virtual address to its
corresponding physical address in memory.

6. Fixed Size:
The key advantage of paging is that both pages and frames are of the
same fixed size. This simplifies memory management and avoids
external fragmentation (wasted space between allocated blocks).
▪ Segmentation: Dividing memory into logical segments (code, data,
stack).

◦ Diagram (Segment Table Translation):

▪ CPU generates Logical Address (Segment Number | Offset).

▪ Segment Number used as index into Segment Table.

▪ Segment Table Entry contains Base Address and Limit.

▪ Check Offset < Limit. If so, Base Address + Offset gives Physical Address.

• Thrashing: Excessive paging activity due to too many processes

competing for memory.

◦ Graph: Y-axis: CPU Utilization, X-axis: Degree of Multiprogramming.

Shows a peak and then a sharp decline as thrashing sets in.

• Cache Coherence: (Reiterated from Design Issues) Essential to ensure

consistency of data across multiple CPU caches.

• Cache coherence : In a multiprocessor system, data inconsistency may

occur among adjacent levels or within the same level of the memory
hierarchy. In a shared memory multiprocessor with a separate cache
memory for each processor, it is possible to have many copies of any one
 instruction operand: one copy in the main memory and one in each cache
memory. When one copy of an operand is changed, the other copies of
the operand must be changed also. Example : Cache and the main
memory may have inconsistent copies of the same object.

Module-2 1-08-2025
Distributed Operating Systems: System Architectures- Design issues –
Communication models – clock synchronization – mutual exclusion – election
algorithms- Distributed Deadlock detection.

Distributed Operating System-Manages a collection of independent

computers
and makes them appear to the users of the
system as if it were a single computer.

1. System Architectures
1. Client-Server Model
2. Peer-to-Peer Model
3. Data-Centic Architecture Model
4. Layered Architecture
• Client Server Architecture in Distributed
Systems
Client-Server Architecture is a foundational model in distributed systems
where the system is divided into two main components: clients and
servers. This architecture defines how tasks and services are distributed
across different entities within a network.
• In Client-Server Architecture, clients request services or resources,
while servers provide those services or resources.
• The client initiates a request to the server, which processes the
request and returns the appropriate response.
• This model centralizes the management of resources and services
on the server side, while the client side focuses on presenting

information and interacting with users.

Key Principles of Client Server Architecture in
Distributed Systems
• Separation of Concerns:
Function: Clients handle user interactions and requests, while servers
manage resources, data, and business logic.
• Centralized Management:
Function: Servers centralize resources and services, making them
accessible to multiple clients.
• Request-Response Model:
Function: Clients send requests to servers, which process these
requests and send back responses.
• Scalability:
Function: Servers can be scaled to handle increasing numbers of clients
or requests.
• Security:
Function: Security mechanisms are often implemented on the server
side to control access and manage sensitive data.

• Peer-to-Peer (P2P)
Peer-to-Peer (P2P) Architecture is a decentralized network design where each node, or
"peer," acts as both a client and a server, contributing resources and services to the
network. This architecture contrasts with traditional client-server models, where nodes
have distinct roles as clients or servers.

• In a P2P architecture, all nodes (peers) are equal participants in the network, each
capable of initiating and receiving requests.
 • Peers collaborate to share resources, such as files or computational power, without

relying on a central server.

Key Features of Peer-to-Peer (P2P) Architecture in Distributed Systems

• Decentralisation
◦ Function: There is no central server or authority. Each peer operates
independently and communicates directly with other peers.
◦ Advantages: Reduces single points of failure and avoids central bottlenecks,
enhancing robustness and fault tolerance.
• Resource Sharing
◦ Function: Peers share resources such as processing power, storage space, or
data with other peers.
 ◦ Advantages: Increases resource availability and utilization across the network.
• Scalability
◦ Function: The network can scale easily by adding more peers. Each new peer
contributes additional resources and capacity.
◦ Advantages: The system can handle growth in demand without requiring significant
changes to the underlying infrastructure.
• Self-Organization
◦ Function: Peers organize themselves and manage network connections
dynamically, adapting to changes such as peer arrivals and departures.
◦ Advantages: Facilitates network management and resilience without central
coordination.

• Data-Centric Architecture
Data-Centric Architecture is an architectural style that focuses on the central
management and utilisation of data. In this approach, data is treated as a critical
asset, and the system is designed around data management, storage, and retrieval
processes rather than just the application logic or user interfaces.

• The core idea of Data-Centric Architecture is to design systems where data is

the primary concern, and various components or services are organized to
support efficient data management and manipulation.
 • Data is centrally managed and accessed by multiple applications or services,

ensuring consistency and coherence across the system

Key Principles of Data-Centic Architecture in Distributed Systems

• Centralized Data Management:

◦ Principle: Ensures data consistency and integrity by maintaining a single
source of truth.
• Data Abstraction:
◦ Principle: Simplifies data access and manipulation while hiding the
underlying complexity.
• Data Normalization:
 ◦ Principle: Enhances data quality and reduces data anomalies by
ensuring consistent data storage.
• Data Integration:
◦ Principle: Supports interoperability and facilitates comprehensive data
analysis across diverse data sources.
• Scalability and Performance:
◦ Principle: Ensures the system can scale to accommodate growing data
needs while maintaining performance.

• Layered Architecture
Layered Architecture in distributed systems organizes the system into hierarchical
layers, each with specific functions and responsibilities. This design pattern helps
manage complexity and promotes separation of concerns. Here’s a detailed
explanation:

• In a layered architecture, the system is divided into distinct layers, where

each layer provides specific services and interacts only with adjacent layers.
 • This separation helps in managing and scaling the system more effectively.

• Layers and Their Functions

• Presentation Layer
◦ Function: Handles user interaction and presentation of data. It is responsible
for user interfaces and client-side interactions.
• Application Layer
◦ Function: Contains the business logic and application-specific functionalities.
 • Middleware Layer
◦ Function: Facilitates communication and data exchange between different
components or services.
• Data Access Layer
◦ Function: Manages data storage and retrieval from databases or other data
sources.

2. Design issues

• Transparency: Making the distribution of resources invisible to

the user.
• Heterogeneity: Dealing with different hardware and software
platforms.
• Openness: Ability to easily extend and configure the system.
• Scalability: Ability to handle increasing numbers of users and
resources.
• Fault Tolerance: Ability to continue operating despite failures.
• Security: Protecting resources from unauthorized access.

3. Communicationmodels. 02-8-25
1. Remote Procedure Call(RPC)
2. Remote Method Invocation(RMI)
Remote Procedure Call(RPC): RPC allows a process on one machine to
call a procedure (or function) located on another machine transparently,
as if it were a local call.

Remote Procedure Call (cont.)

• Client procedure calls the client stub in a normal way
• Client stub builds a message and traps to the kernel
• Kernel sends the message to remote kernel
• Remote kernel gives the message to server stub
• Server stub unpacks parameters and calls the server
• Server computes results and returns it to server stub
• Server stub packs results in a message and traps to kernel
• Remote kernel sends message to client kernel
• Client kernel gives message to client stub
• Client stub unpacks results and returns to client.
Remote Method Invocation: RMI is the object-oriented
counterpart to RPC. It allows an object in one process to invoke a method
on an object in another process, even if they are on different machines.

• Mechanism: The mechanism is similar to RPC, using stubs and skeletons

to handle communication. The key difference is that RMI can pass full-
fledged objects as parameters, not just data. In systems like Java RMI,
this can include the object's code (via serialisation), allowing for more
dynamic and powerful interactions.

• Analysis: RMI provides a more natural and seamless programming

model for distributed applications built using object-oriented languages.
It preserves the object-oriented paradigm across machine boundaries.
The primary drawback is that RMI systems are often language-specific
(e.g., Java RMI is specific to Java), whereas RPC is designed to be

interoperable across different languages and platforms.

How RMI Works: The magic of RMI is achieved through two helper
objects: the stub and the skeleton.
1. Client and Stub (Proxy):
• The client application holds a reference to a local object called a
stub.
• This stub acts as a proxy for the remote object. It has the same
methods as the remote object.
• When the client calls a method on the stub, it is not executing the
remote code.
1. Marshalling:
• The stub's job is to take the method name and its parameters and
package them into a message. This process of converting the
parameters into a byte stream suitable for network transmission is
called marshalling.
1. Communication:
• The stub sends this message over the network to the server
machine where the actual object resides.
1. Skeleton and Unmarshalling:
• On the server side, a skeleton object receives the message.
• The skeleton's job is to unmarshal the message—unpacking the
byte stream to retrieve the method name and parameters.
1. Actual Invocation:
• The skeleton then uses this information to call the actual method
on the real object on the server.
1. Return Path:
• The process is reversed for the return value. The skeleton marshals
the return value, sends it back across the network, and the client's
stub unmarshals it and returns it to the client application.

From the client's perspective, it simply called a method. The stub,

skeleton, and network layers handle all the complex details of
communication, making distributed programming significantly easier.

4. Election Algorithms
In many distributed applications, one process must act as a coordinator.
Election algorithms are used to choose a new coordinator when the
current one fails or when the system initialises. The goal is for all live
processes to agree on a single coordinator.

- The Bully Algorithm

This algorithm assumes that every process has a unique priority number
(ID) and that every process knows the IDs and addresses of all other
processes. The process with the highest ID is elected as the coordinator.

• Algorithm Steps:
1. When a process P detects that the coordinator has failed, it initiates
an election.
2. P sends an ELECTION message to all processes with a higher ID than
itself.
3. P then waits for a response.
• If no process with a higher ID responds within a timeout period, P
considers itself the winner. It becomes the new coordinator and
sends a COORDINATOR message to all processes with lower IDs to
announce its victory.
If a process with a higher ID, say Q, receives the ELECTION message, it
sends an OK message back to P, indicating that it is alive and will take
over. P's role in the election is now over. Process Q then starts its own
election by sending ELECTION messages to all processes with IDs higher
than its own.

Analysis: The algorithm gets its name because higher-ID processes

"bully" lower-ID processes out of the election. It is relatively simple but
can be inefficient. In the worst-case scenario, where the process with the
lowest ID initiates the election, it results in a cascade of elections,
generating O(N2) messages.

• The Ring Algorithm

This algorithm assumes that the processes are organised in a logical
ring, where each process knows the address of its successor.

• Algorithm Steps:
1. When a process P detects a coordinator failure, it creates an
ELECTION message containing its own ID and sends it to its
successor in the ring.
2. When a process Q receives an ELECTION message, it appends its
own ID to the list in the message and forwards it to its successor.
3. This continues until the message circulates the entire ring and
returns to the initiator, P.
4. At this point, P has a list of all the live processes in the ring. It can
then apply a rule (e.g., choose the process with the highest ID) to
select the new coordinator.
5. P circulates a final COORDINATOR message around the ring to
announce the winner.

6. Analysis: The Ring algorithm is more message-efficient than the

Bully algorithm, always requiring 2(N−1) messages in a system of N
live processes. However, it relies on the integrity of the logical ring
structure and can be slower as messages must traverse the entire
ring.

• Distributed Deadlock Detection

• Consider a wait-for graph where P1 →P2 , P2 →P3 , and P3 →P1 .

7. P1 blocks waiting for a resource held by P2 . P1 's site initiates
detection by sending a probe (1,1,2) to P2 's site.
8. P2 's site receives the probe. It sees that P2 is blocked waiting for a
resource held by P3 . It propagates the probe by sending (1,2,3) to
P3 's site.
9. P3 's site receives the probe. It sees that P3 is blocked waiting for a
resource held by P1 . It propagates the probe by sending (1,3,1) to
P1 's site.
10. P1 's site receives the probe (1,3,1). Since the initiator of the probe
(the first element, '1') is the same as the process on this site, a
deadlock is declared.

• Analysis: The algorithm is fully distributed, requires very little

overhead (probe messages are small), and does not report false
deadlocks. Its main challenge is in deadlock resolution, as each
site only knows about the cycle involving itself, not necessarily the
full set of processes involved in the deadlock across the system.

Module3: Distributed Scheduling,

Shared Memory & File Systems
1. Distributed Scheduling
• Tasks allocated by a scheduler to minimize idle time and maximise
throughput.
User Submits Job
↓
Scheduler
↓
Resource Manager
↓
Worker Nodes
↓
Monitor/Logger

Distributed scheduling involves the allocation of tasks to processors

across multiple nodes in a distributed system. The primary objectives are
to improve overall system performance through load sharing and to
reduce the average response time for processes. A good distributed
scheduling algorithm should be scalable, fault-tolerant, and dynamic,
making decisions without complete prior knowledge of process
behaviour.

• Task Allocation vs. Scheduling: Task allocation refers to the

process of assigning a task to a specific node for execution, while
task scheduling determines the order in which tasks are executed
on that node.
• Load Balancing Strategies: These are policies for redistributing
the workload among nodes to prevent situations where some
nodes are overloaded while others are idle.
• Static Load Balancing: Decisions are made at compile time
based on average system behaviour. Algorithms like Round-Robin
or random allocation fall into this category. They are simple but
cannot adapt to dynamic changes in system load.

• Dynamic Load Balancing: Decisions are made at runtime based

on the current state of the system. Algorithms like Least
Connection (send task to the node with the fewest active
connections) or Least Response Time are more complex but offer
better performance by adapting to real-time conditions.
• Task Migration: A key mechanism in dynamic load balancing is
task migration, which involves moving a partially executed task
from an overloaded node to a less-loaded one. This is a complex
operation that requires transferring the process's state, including
its address space and execution context, across the network.

Distributed and Multimedia File Systems

A Distributed File System (DFS) is a file system that manages the storage
and access of files across multiple autonomous computers in a network.
The primary goal of a DFS is to provide location transparency and access
transparency, making the distributed files appear to users as if they are
stored on their local machine.

Mechanisms For Building Distributed File Systems

1. Mounting
2. Caching
3. Hints
4. Bulk Data Transfer
5. Encryption

• Architecture of DFS: A typical DFS uses a client-server

architecture. File servers store the files and provide an interface
for clients to access them. Clients have a DFS client module that
intercepts file system calls, determines if the request is for a local
or remote file, and communicates with the appropriate file server if
necessary.
• Design Issues: Key design issues include naming and location
transparency, caching strategies to improve performance, fault
tolerance through replication, and maintaining file consistency
when multiple clients access the same file concurrently.

3.3.1 Multimedia File Systems

Multimedia file systems are a specialised type of file system designed to

handle the unique requirements of continuous media data, such as audio
and video. Unlike traditional data, multimedia data is time-sensitive and
requires real-time delivery with Quality of Service (QoS) guarantees.

• Key Characteristics:
• Real-time Requirements: Files must be delivered at a constant
rate to avoid jitter or gaps in playback. This requires the file
system and the OS to support real-time scheduling.
• Large File Sizes: Multimedia files are typically very large,
requiring efficient storage and retrieval mechanisms.
• QoS Guarantees: The system must be able to guarantee specific
levels of bandwidth, delay, and jitter to ensure smooth playback.
• Design Considerations: Multimedia file systems often use
different file placement strategies, such as storing continuous
media blocks contiguously on disk to minimize seek times. They
also require sophisticated buffer management and network
protocols that can provide the necessary QoS guarantees.

3.4 File Placement and Caching

In a DFS, how and where files are stored (placement) and how copies are
temporarily stored closer to the user (caching) are critical for
performance, availability, and scalability.
• File Placement (Replication): File placement strategies
determine on which servers to store files and their replicas. The
goal is to improve reliability and performance. By creating multiple
copies (replicas) of a file on different servers, the system can
tolerate server failures and can also improve read performance by
allowing clients to access the replica that is closest to them or
least loaded. The main challenge is keeping all replicas consistent
when the file is updated.
• Caching: Caching is a fundamental technique for improving DFS
performance. When a client accesses a remote file, a copy of the
data is stored in a local cache on the client's machine. Subsequent
accesses to the same data can be served from the local cache,
which is much faster than fetching it over the network again.
• Cache Location: Caches can be located in the client's main
memory or on its local disk.
• Cache Consistency: The main challenge with caching is ensuring
that the cached copies do not become stale. When a file is
modified on the server, all cached copies of that file on various
clients must be either updated or invalidated. This requires a
cache consistency protocol, similar in principle to those used for
multiprocessor cache coherence.

Module 04:Database Operating Systems 3-8-25

A Database Operating System (DBOS) is a specialized operating system
designed to support the unique requirements of a database management
system (DBMS). While a DBMS can run on a general-purpose OS, a dedicated
DBOS can provide significant performance and functionality advantages by
tailoring its services—such as memory management, process scheduling, and
I/O handling—to the specific patterns of database workloads.

4.1 Requirements of a Database OS

A DBOS must provide services beyond those of a standard OS to efficiently

manage large volumes of data and support concurrent transaction processing.

• Buffer Management: A DBMS often implements its own buffer pool

management in user space to have fine-grained control over which data
pages are kept in memory and to implement replacement policies (like
LRU) that are optimized for database access patterns (e.g., sequential
scans vs. random lookups).

• Process and Thread Management: Database systems often manage a

large number of concurrent user connections. A DBOS may support a
lightweight threading model to avoid the high overhead of creating a
separate OS process for each connection.

• Disk I/O Management: The OS should provide mechanisms for efficient,

asynchronous I/O and allow the DBMS to control the layout of data on
disk to optimize for sequential access.

• Transaction Support: This is the most critical requirement. The OS

must provide underlying support for the atomicity, consistency, isolation,
and durability (ACID) properties of transactions.
4.2 Transaction Process Mode

A transaction is a sequence of operations that are performed as a single logical

unit of work. The transaction model ensures data integrity in the face of

concurrent access and system failures.

• ACID Properties:

◦ Atomicity: A transaction is an "all or nothing" operation. Either all

of its operations are completed successfully, or none of them are.
 ◦ Consistency: A transaction must bring the database from one
valid state to another.

◦ Isolation: The execution of one transaction must be isolated from

that of other concurrent transactions. To the user, it should appear
as if transactions are executed serially.

◦ Durability: Once a transaction has been committed, its effects are

permanent and must survive any subsequent system failure.

4.3 Synchronization Primitives

To ensure isolation, a DBMS must use synchronization primitives to control

access to shared data objects. While general-purpose primitives like
semaphores can be used, databases typically employ more specialised locking
mechanisms.

• Locks: A lock is a variable associated with a data item that describes the
status of the item with respect to possible operations that can be applied
to it.

◦ Shared (Read) Lock: Allows multiple transactions to read the

same data item concurrently.

◦ Exclusive (Write) Lock: Allows only one transaction to access the

data item for writing, and no other transaction can read or write it.
4.4 Concurrency Control Algorithms(refer slide). mod5

Concurrency control algorithms are the mechanisms that ensure the isolation
and consistency of transactions.

• Locking-Based Protocols:

◦ Two-Phase Locking (2PL): This is the most common protocol. It

dictates that a transaction must acquire all the locks it needs
before it starts releasing any locks. This protocol has a "growing
phase" where it acquires locks and a "shrinking phase" where it
releases them. Strict 2PL, which holds all exclusive locks until the
transaction commits, is often used to prevent cascading rollbacks.
While 2PL guarantees serializability, it can lead to deadlocks.

• Timestamp-Based Protocols:

◦ Each transaction is assigned a unique timestamp when it starts.

The protocol uses these timestamps to determine the serializability
order of transactions. If a transaction tries to access data that has
been modified by a younger transaction (one with a later
timestamp), the older transaction is typically aborted and
 restarted. This approach is deadlock-free but can cause more
transaction rollbacks than locking.

• Optimistic Concurrency Control (Validation-Based)

This approach is based on the assumption that conflicts between transactions

are rare. Transactions are allowed to execute without any locking. When a
transaction is ready to commit, it enters a validation phase where the system
checks if its execution has violated serializability. If a conflict is detected, the
transaction is rolled back. This method works well in systems with low data
contention.

Validation-Based Protocol, also known as Optimistic Concurrency Control,

is a technique in DBMS used to manage concurrent transactions without
locking data during execution. It assumes that conflicts between
transactions are rare and delays conflict detection until the validation
phase just before committing.
Why It's Called Optimistic Concurrency Control

• Assumes low interference among transactions.

• Does not check for conflicts during execution.
• All updates are done on local copies.
• At the end, a validation check ensures data consistency before
writing to the database.

Phases of Validation-Based Protocol

This protocol operates in three main phases:
1. Read Phase:

• The transaction reads data and performs calculations using

temporary (local) variables.
• No changes are made to the database yet.

2. Validation Phase:
 • Before committing, the transaction checks for conflicts with other
concurrently running transactions.
• If no conflict is found (i.e., serializability is preserved), it proceeds
to the write phase.
• If validation fails, the transaction is aborted and restarted.

3. Write Phase:

• If validation passes, the transaction writes changes to the

database.
• If validation fails, the transaction is aborted and may be restarted.

Chapter 5: Mobile Operating Systems

Mobile operating systems are designed for the unique constraints and use
cases of handheld devices like smartphones and tablets. They must manage
resources in an environment characterized by limited battery power, smaller
screen sizes, diverse wireless connectivity, and different hardware
architectures compared to traditional desktop and server systems.

5.1 ARM and Intel Architectures

The underlying processor architecture heavily influences the design of a mobile

OS. The two dominant architectures in the mobile space are ARM and Intel
(x86).
 • ARM Architecture: ARM processors are based on a RISC (Reduced
Instruction Set Computing) architecture. This design philosophy
emphasizes a smaller, simpler set of instructions that execute quickly.
ARM processors are known for their exceptional power efficiency, making
them the dominant choice for the vast majority of smartphones and

mobile devices where battery life is a paramount concern.

ARM unique business model allows tech companies to customize and

build processors for diverse devices, from smartphones and tablets to
computers and smart devices. Their exceptional balance of processing
power and energy efficiency has made them the preferred choice for
mobile computing, enabling longer battery life without compromising
performance.

✅ Features of ARM Processor

1. Multiprocessing Support

• ARM supports multiple cores (from 1 to 8 or more).

• Early support for Asymmetric Multiprocessing (AMP) (ARMv6K).

• Common in multi-core SoC (System on Chip) designs for better

multitasking and performance.

2. Tightly Coupled Memory (TCM)

• Very fast and low-latency memory.

• Used where cache memory is unpredictable.

• Ensures deterministic access → ideal for real-time and safety-

critical systems.
3. Memory Management

• Has MMU (Memory Management Unit) and MPU (Memory

Protection Unit):

◦ MMU: Handles virtual memory, allows OS like Linux to run.

◦ MPU: Protects memory areas from being overwritten.

• Enables secure and efficient memory use.

4. Thumb-2 Technology

• Uses mixed 16-bit and 32-bit instructions.

• Advantages:
 ◦ Reduces memory usage.

◦ Improves performance.

◦ Compatible with existing ARM instructions.

5. One-Cycle Execution

• Most instructions complete in just one clock cycle (CPI = 1).

• Fixed instruction size makes instruction fetch and execution faster.

6. Pipelining

• Instructions are processed in stages, like an assembly line.

• Allows parallel execution.

• Increases overall instruction throughput (more instructions per unit

time).
7. Large Number of Registers

• ARM CPUs have many general-purpose registers.

• Benefits:

◦ Reduces the need to access slow memory.

◦ Speeds up data access and execution.

◦ Improves system efficiency and performance.

Advantages of ARM processor

• Low Power Consumption : Ideal for battery-powered and mobile

devices.
• High Performance per Watt : Efficient processing with minimal
energy use.
• Compact and Simple Design : Reduces manufacturing costs and
chip size.
 • RISC Architecture : Simplifies instructions, enabling faster
execution.
• Wide Ecosystem Support : Extensive software and development
tools.
• Scalability : Used in a variety of devices from microcontrollers to
smartphones.
• Cost-Effective Licensing Model : Enables broad adoption by
manufacturers.

• Intel Mobile Architecture: Intel's mobile processors are based on the

x86 architecture, which is a CISC (Complex Instruction Set Computing)
design. While historically associated with higher power consumption,
modern Intel mobile chips (like the Atom series) have made significant
strides in power efficiency. Their primary advantage is compatibility with
the vast ecosystem of x86 software.

• Intel x86 (CISC - Complex Instruction Set Computer): Intel's x86

architecture, which has historically dominated the desktop and server
markets, is based on the CISC philosophy. It features a large, powerful set of
variable-length instructions, where a single instruction can perform a complex
multi-step operation (e.g., read from memory, perform an arithmetic
operation, and write back to memory). Historically, this was aimed at
maximizing raw performance, but it leads to more complex chip designs and
higher power consumption. Intel has made significant strides in adapting its
 architecture for mobile power envelopes, but the fundamental design
philosophy remains different from ARM's.
Advantages:

Compatibility: One of the key advantages of the x86 architecture is its

compatibility with older processors. This allows software developed for
older processors to run on newer x86 processors without modification,
which makes it easy to upgrade systems.
Performance: The evolution of x86 microprocessors has resulted in
significant improvements in performance. Each new generation of
processors has been faster and more efficient than the previous one,
which has enabled the development of more advanced applications and
technologies.
Versatility: The x86 architecture is used in a wide range of applications,
from personal computers to servers, embedded systems, and mobile
devices. This versatility has made it one of the most widely used
processor architectures in the world.
Broad Industry Support: The x86 architecture is supported by a large
ecosystem of hardware and software vendors. This broad industry
support has helped to drive innovation and development, resulting in a
range of products that are designed to work with x86 processors.

5.2 Mobile OS Architectures

Modern mobile operating systems, such as Android and iOS, are sophisticated,
layered systems designed to abstract the hardware and provide a rich
application environment.

• Layered Structure: A typical mobile OS architecture can be visualized

as a stack:
1. Kernel: The core of the OS, responsible for process management,
memory management, and device drivers. Android uses a modified
Linux kernel, while iOS uses the XNU kernel.

2. Hardware Abstraction Layer (HAL): Provides a standard

interface for the upper layers to interact with device hardware,
allowing the OS to be independent of specific hardware drivers.

3. Libraries and Runtime: This layer includes a set of C/C++

libraries for core system functions and a managed runtime
environment for applications (e.g., the Android Runtime - ART;
Objective-C/Swift runtime for iOS).

4. Application Framework: Provides high-level services and APIs

that developers use to build applications, such as the UI manager,
location services, and notification manager.
 5. Applications: The top layer, consisting of the user-facing

applications, both native and third-party.

• Kernel Structure and Native Level Programming: The use of a full-

fledged kernel like Linux allows for robust multitasking and security
features. Native level programming, using tools like the Android NDK,
allows developers to write performance-critical parts of their applications
(e.g., games, signal processing) in C/C++, bypassing the managed
runtime for direct access to system libraries.
5.3 Power Management

Power management is arguably the most critical design issue for mobile
operating systems due to the finite capacity of batteries. The OS employs a
variety of aggressive strategies to conserve power.

• Runtime Issues and Approaches:

◦ CPU Power States: The OS dynamically adjusts the CPU's frequency

and voltage (Dynamic Voltage and Frequency Scaling - DVFS) based on
the current workload. When the device is idle, the CPU can be put into a
deep sleep state where it consumes very little power.

◦ Component Power Management: The OS actively manages the power

state of individual hardware components like Wi-Fi, Bluetooth, GPS, and
the display. It powers them down when not in use and powers them up
quickly when needed.

◦ Wake Locks: A wake lock is a mechanism that applications can use to

prevent the system from going into a deep sleep state. While necessary
for background tasks like music playback or data syncing, their misuse is
a common cause of excessive battery drain.

◦ Application Lifecycle Management: Mobile OSs have a stricter

application lifecycle. When an application is not in the foreground, the OS
may suspend or terminate it to free up resources and save power. This
requires applications to be able to save and restore their state efficiently.

◦ Dynamic Voltage and Frequency Scaling (DVFS): The OS adjusts

the CPU's voltage and frequency based on the current workload to save
power
These approaches create a constant trade-off between device responsiveness
and battery longevity. The OS must intelligently predict user behavior and
application needs to make effective power management decisions without
negatively impacting the user experience.