3.

Processes and Threads

3.1 Processes

A process is an instance of a program in execution. Each process has its own memory space,
registers, and resources allocated by the operating system. Processes do not share memory
unless explicitly programmed to do so.

Properties of Processes:

 Isolation: Each process runs in its own address space.

 Concurrency: Multiple processes can run in parallel.
 Communication: Processes communicate through inter-process communication
(IPC) mechanisms.
 Scheduling: The operating system schedules processes using various algorithms
(FCFS, Round Robin, etc.).

3.2 Threads

A thread is a lightweight process that shares memory and resources with other threads within
the same process.

Properties of Threads:

 Shared Resources: Threads within the same process share memory, file descriptors,
and system resources.
 Faster Context Switching: Switching between threads is faster than switching
between processes.
 Synchronization Required: Threads need synchronization mechanisms (locks,
semaphores) to avoid race conditions.

3.3 Multithreading

Multithreading allows multiple threads to execute within the same process, improving
performance and responsiveness.

Example:

 A web browser runs multiple threads:

o One for UI rendering.
o One for downloading content.
o One for handling user interactions.

4. Graph Models for Process Representation

Graph models help visualize dependencies and interactions between processes.

 Process Graph: Represents execution flow of processes.

  Dependency Graph: Shows which processes rely on others.

Example Graph Representation:

P1 → P2 → P3

5. Client/Server Model

 Client: Requests services from a server.

 Server: Provides services to clients.
 Example: Web browser (client) interacting with a web server.

6. Time Services

 Ensures synchronized timekeeping across distributed nodes.

 NTP (Network Time Protocol): Synchronizes clocks over a network.

7. Language Mechanisms for Synchronization

 Locks, Semaphores, and Monitors are used for synchronization.

Language Mechanisms for Synchronization

1. Introduction to Synchronization in Distributed Systems

Synchronization is crucial in distributed systems to coordinate concurrent processes and

threads. Without proper synchronization mechanisms, race conditions, deadlocks, and
inconsistent data may occur.

A synchronization mechanism ensures:

 Mutual Exclusion – Only one process accesses a shared resource at a time.

 Coordination – Processes operate in a predefined order.
 Deadlock Prevention – Avoids circular waiting between processes.
 Consistency – Ensures shared data remains valid and correct.

2. Types of Synchronization Mechanisms

2.1 Locks

Locks restrict access to shared resources to one process at a time.

Types of Locks:

 Mutex (Mutual Exclusion Lock): Allows only one process to enter the critical
section.
 Read/Write Locks: Allows multiple readers but only one writer.
2.2 Semaphores

A semaphore is a signaling mechanism that controls access to resources.

Types of Semaphores:

 Binary Semaphore (0 or 1) – Similar to a mutex, but with signaling.

 Counting Semaphore – Allows multiple processes to access a resource up to a limit.

2.3 Monitors

A monitor is a high-level synchronization construct that provides mutual exclusion using

built-in mechanisms.

 Monitors encapsulate shared resources.

 Methods ensure only one process executes critical sections at a time.
 Used in object-oriented languages like Java.

2.4 Barriers

Barriers ensure that a group of processes reach a synchronization point before proceeding.

2.5 Condition Variables

Condition variables allow processes to wait until a certain condition is met.

3. Synchronization in Distributed Systems

In distributed environments, synchronization faces additional challenges:

 Clock Skew – Different system clocks may not be perfectly synchronized.

 Message Delays – Network latency can impact coordination.
 Fault Tolerance – Synchronization mechanisms must handle failures.

Solutions for Distributed Synchronization

1. Logical Clocks – Ensure event ordering (e.g., Lamport timestamps).

2. Distributed Locks – Use algorithms like Ricart-Agrawala for mutual exclusion.
3. Leader Election – Selects a coordinator to manage synchronization.

Example: Distributed Mutual Exclusion Using Ricart-Agrawala Algorithm

 A process requests a lock by sending a timestamped message to others.

 If no higher-priority request exists, the process enters the critical section.
 Once done, it releases the lock and notifies waiting processes.
8. Object Model Resource Servers

 Resource servers manage shared resources like files and databases.

 Example: File servers, database servers.

Object Model Resource Servers

In a distributed system, resource servers are specialized servers that manage and provide
access to shared resources like files, databases, printers, and computational power. These
servers follow an object-based model, where resources are treated as objects that can be
accessed and manipulated remotely.

8.1 Object Model Overview

The object model in distributed systems is based on the concept of encapsulation,

inheritance, and polymorphism, allowing efficient resource management.

Key features of the Object Model:

 Encapsulation: Resources are represented as objects with defined interfaces.

 Remote Access: Clients interact with resource objects using remote method calls.
 Concurrency Handling: Multiple clients can access the resource concurrently while
ensuring consistency.

8.2 Components of an Object Resource Server

A resource server typically consists of the following components:

1. Object Repository – Stores objects representing resources.

2. Object Manager – Manages object creation, deletion, and updates.
3. Access Control Module – Ensures secure access to resources.
4. Request Handler – Processes client requests for resource access.
5. Synchronization Mechanism – Ensures consistency when multiple clients access the
same resource.

8.3 Working of an Object Model Resource Server

1. Client requests access to a resource via an interface.

2. The server verifies authentication and checks access permissions.
3. If authorized, the server locates the requested resource and returns a reference.
4. The client performs operations on the resource via remote method invocation (RMI).
5. The server ensures synchronization and consistency before returning results.

8.4 Examples of Object Model Resource Servers

 File Servers – Provide access to shared files (e.g., NFS, SMB).

  Database Servers – Store and manage data (e.g., MySQL, PostgreSQL).
 Print Servers – Handle printing requests from multiple clients.

9. Inter-process Communication and Coordination

 Message Passing: Direct communication via messages.

 Request/Reply Model: Clients request services, and servers reply.
 Transaction Communication: Ensures atomic execution.
 Shared Memory: Allows processes to communicate via shared memory segments.
 RPC (Remote Procedure Call) & RMI (Remote Method Invocation) Case
Studies: Used for communication between distributed systems.

Inter-process Communication and Coordination

1. Introduction

Inter-process communication (IPC) allows independent processes in a distributed system to

exchange information and coordinate their activities. Since processes may be running on
different machines in a network, IPC mechanisms are crucial for synchronization, resource
sharing, and consistency.

Challenges in IPC

 Heterogeneity – Different operating systems and architectures.

 Latency & Network Failures – Message delays and packet loss.
 Security – Data must be protected from unauthorized access.
 Synchronization – Ensuring proper sequence of communication.

2. Types of IPC Mechanisms

2.1 Message Passing

Message passing is the primary form of IPC in distributed systems. It allows processes to
send and receive messages over a network.

Types of Message Passing:

1. Synchronous Communication – The sender waits until the receiver acknowledges

the message.
2. Asynchronous Communication – The sender sends the message and continues
execution without waiting for a response.
2.2 Request/Reply Model

A process (client) requests a service from another process (server), and the server replies with
a response.

Example:

 Web browser (client) sends a request to a web server.

 The server processes the request and sends a response back.

2.3 Transaction Communication

 Ensures that operations are atomic and consistent.

 Uses the ACID properties (Atomicity, Consistency, Isolation, Durability).
 Common in databases and financial systems.

Transaction Communication: Ensuring Atomic Execution

1.1 Introduction

A transaction is a sequence of operations that must be executed atomically, meaning either

all operations execute successfully, or none do. Transaction communication ensures data
integrity, consistency, and fault tolerance in distributed systems.

1.2 ACID Properties of Transactions

1. Atomicity – The transaction is all-or-nothing. If any part fails, the entire transaction is
rolled back.
2. Consistency – The system remains in a valid state before and after the transaction.
3. Isolation – Transactions execute independently without interfering with each other.
4. Durability – Once a transaction is committed, its changes are permanent.

1.3 Transaction Models in Distributed Systems

1. Flat Transactions – A single transaction that either commits or aborts.

2. Nested Transactions – A parent transaction with sub-transactions, where all must
succeed for a commit.
3. Distributed Transactions – Transactions involving multiple nodes across a network.

1.4 Two-Phase Commit Protocol (2PC)

A 2PC protocol is used to ensure all distributed components agree before committing a
transaction.

Steps in 2PC:

Phase 1: Prepare Phase

  The coordinator asks all participating nodes if they can commit.
 Each node replies "Yes" (Prepared) or "No" (Abort).

Phase 2: Commit or Abort Phase

 If all nodes reply "Yes," the transaction is committed.

 If any node replies "No," the transaction is aborted.

Example:

 A bank transaction where money is transferred between two accounts.

 The transfer must either fully complete or fully abort to maintain consistency.

RPC (Remote Procedure Call) & RMI (Remote Method Invocation)

1. Remote Procedure Call (RPC)

RPC is a mechanism that allows a process to call a procedure (function) in another address
space, typically on a remote system, as if it were a local procedure call. It abstracts the
communication complexities, making remote execution seamless.

Working of RPC

1. Client Stub: The client process calls a local stub function instead of directly calling
the remote function.
2. Marshalling: The client stub serializes the request parameters and sends them over
the network.
3. Request Transmission: The request is sent to the remote server via the network.
4. Server Stub: The server receives the request, unmarshals the parameters, and calls
the actual procedure.
5. Execution: The procedure executes on the remote machine.
6. Response Transmission: The result is marshalled and sent back to the client.
7. Client Stub Unmarshalling: The client stub receives the response, unmarshals it, and
returns it to the caller.
Components of RPC

 Client Process: Requests the remote service.

 Client Stub: Acts as a local representative of the remote procedure.
 RPC Runtime System: Handles communication, message passing, and failure
handling.
 Server Stub: Receives client requests and forwards them to the actual service.
 Server Process: Executes the requested service and sends the response.

2. Remote Method Invocation (RMI)

RMI is an extension of RPC that enables objects to invoke methods on remote objects. Unlike
RPC, RMI supports object-oriented communication by passing objects rather than just data.

Working of RMI

1. Stub Generation: The client creates a stub (proxy) for the remote object.
2. Binding with Registry: The server registers the remote object in an RMI registry.
3. Lookup: The client looks up the remote object in the registry.
4. Remote Method Invocation: The client calls a method on the remote object.
5. Marshalling & Transmission: The method parameters are serialized and sent to the
server.
6. Execution: The server executes the method and sends back the result.
7. Response Handling: The client stub receives the result and returns it to the client
process.
Components of RMI

 Remote Interface: Defines the methods that can be invoked remotely.

 Stub & Skeleton: Acts as a proxy for communication.
 RMI Registry: A lookup service that allows clients to locate remote objects.
 Remote Object: The actual implementation of the remote service.

Differences Between RPC and RMI

Feature RPC RMI

Communication Model Function-based Object-oriented
Data Passing Sends primitive data Can pass objects
Registry No registry needed Uses RMI registry
May require additional
Platform Dependency Platform-independent (Java-based)
support
More complex due to object
Complexity Less complex
serialization