









Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
operating systems manage multiple processes running at the same time without causing chaos. The notes cover everything from the basics of why synchronization is needed, all the way to the classic problems every OS student has to know. Here's what's inside: Why process synchronization matters and what happens when it goes wrong (race conditions) The Critical Section Problem and the three rules any good solution must follow Peterson's Algorithm — the classic two-process software solution How hardware helps with atomic instructions like Test-and-Set and Swap Mutex Locks and how they work step by step Semaphores The four classic problems: Producer-Consumer, Readers-Writers, Dining Philosophers, and Sleeping Barber Monitors ,Deadlocks and the Banker's Algorithm
Typology: Lecture notes
1 / 15
This page cannot be seen from the preview
Don't miss anything!










Process Synchronization coordinates concurrent processes accessing shared resources (like memory, files) to ensure data consistency and prevent conflicts, primarily by solving the race condition problem where unpredictable execution order leads to errors. It ensures only one process modifies shared data at a time (mutual exclusion) within a critical section, using techniques like semaphores, mutexes, and locks to maintain integrity and avoid issues like deadlocks. Background & Need Concurrent Execution : Modern OS run many processes/threads simultaneously, often sharing common data. Cooperating Processes : Processes that share resources need coordination. The Problem (Race Condition): When multiple processes access and change shared data concurrently, the final outcome depends on the unpredictable order of execution, leading to data corruption or incorrect results.
balance simultaneously. Critical Section: The specific code segment where shared data is accessed, needing protection. Core Objectives Mutual Exclusion: Ensure only one process is in its critical section at any time. Data Consistency & Integrity: Maintain correct, predictable state of shared data. Prevent Deadlocks: Avoid situations where processes wait indefinitely for each other.
Mutex Locks (Mutual Exclusion Locks): A simple locking mechanism where a process acquires a lock before entering the critical section and releases it upon exit. Semaphores : More advanced signaling mechanisms (counting or binary) to control access, allowing multiple processes up to a certain limit. Monitors: High-level synchronization constructs that encapsulate shared data and procedures, ensuring only one process can be active within the monitor at a time. Atomic Operations: Hardware-supported instructions that execute as a single, indivisible unit (e.g., Test-and-Set), crucial for implementing locks.
The critical section problem in operating systems addresses how to protect shared resources when multiple processes or threads need to access them concurrently. It ensures that only one process can access the shared resource at a time, preventing data corruption and inconsistencies. Solutions to this problem, like Peterson's Algorithm and Mutex Locks, aim to satisfy mutual exclusion, progress, and bounded waiting. A critical section is a code segment that accesses shared resources (like memory, variables, or peripherals). It's crucial that only one process or thread is allowed to execute this code at a time to prevent race conditions and maintain data integrity. Key Concepts Shared Resources: Data, variables, files, or hardware that multiple processes need to access. Critical Section: The part of a process's code that accesses shared resources. Race Condition : A situation where the system's behavior depends on the unpredictable order of process execution, leading to errors. Structure of a Process A process typically has four parts related to synchronization:
Peterson’s Solution Peterson's Solution is a classic, software-based algorithm for two processes to achieve mutual exclusion (only one process in the critical section) while sharing a resource, preventing race conditions using simple shared variables. Although providing key properties like mutual exclusion, progress, and bounded waiting, it's generally not used in modern systems due to reliance on specific hardware memory models. Key Properties
Mutual Exclusion: Only one process in the critical section. Progress: If no one is in the critical section and someone wants in, only waiting processes are considered. Bounded Waiting: A limit on how many times other processes can enter before a process gets its turn, preventing starvation. Synchronization Hardware Synchronization hardware uses atomic hardware instructions , like Test-and-Set and Swap , to solve the critical section problem by ensuring shared resources aren't accessed concurrently, preventing data corruption. These instructions perform a read-modify-write operation as a single, indivisible (atomic) step, allowing efficient mutual exclusion without complex software locks, though they often lead to busy-waiting. Key Hardware Instructions Test-and-Set: An atomic function that reads a Boolean lock variable,
o How it works: If the original value was false, the process gets the lock and enters the critical section; if true, it keeps trying until the lock becomes false (busy-waiting). Swap (or Exchange): Atomically exchanges the contents of two memory locations (e.g., a lock variable and a process's local variable). o How it works: Similar to Test-and-Set, it allows processes to check and acquire a lock in one uninterruptible step, using a Boolean flag for mutual exclusion. How They Solve Synchronization
Synchronization: Coordinates actions between threads, like in the Producer-Consumer problem, ensuring orderly access
A semaphore is a synchronization tool, an integer variable used to control access to shared resources by multiple processes, preventing conflicts like race conditions, by managing critical sections through atomic wait() (P) and signal() (V) operations. They act like tokens, allowing only a certain number of processes to proceed, with two main types: Binary Semaphores (0 or 1, like a lock) and Counting Semaphores (any non- negative integer, for multiple identical resources). Semaphores are synchronization tools in operating systems used to manage access to shared resources among multiple processes or threads, preventing race conditions and ensuring data consistency. They act as a signaling mechanism, allowing processes to coordinate their actions and prevent simultaneous access to critical sections of code. Key Concepts: Synchronization: Semaphores ensure that processes or threads access shared resources in a controlled and orderly manner, preventing conflicts and data corruption. Critical Section: A critical section is a piece of code that accesses a shared resource and must be executed atomically (without interruption) to maintain data integrity. Wait/Signal Operations: Semaphores use wait() (also known as P or down) and signal() (also known as V or up) operations to control access to shared resources. Counting Semaphores: These semaphores can have values greater than 1, allowing multiple processes to access a resource simultaneously up to a certain limit. Binary Semaphores:
These semaphores have a value of either 0 or 1, acting as a mutex (mutual exclusion lock) to ensure that only one process can access a resource at a time. How Semaphores Work:
1. Resource Availability: A semaphore is initialized with a value representing the number of available units of a shared resource. 2. Wait/P Operation: When a process needs to access a resource, it performs a wait() operation. If the semaphore's value is positive, the process can acquire a unit of the resource (the semaphore value is decremented), and it can proceed to the critical section. If the value is 0, the process waits until the resource becomes available. 3. Signal/V Operation: When a process has finished using the resource, it performs a signal() operation, which increments the semaphore's value, making the resource available for other waiting processes. Benefits of Using Semaphores: Process Synchronization: Semaphores enable processes to coordinate their activities and ensure that they don't interfere with each other when accessing shared resources. Resource Management: Semaphores help manage access to shared resources, preventing race conditions and data inconsistency. Data Integrity: By controlling access to shared resources, semaphores ensure that data is not corrupted or modified by multiple processes simultaneously. Critical Section Protection: Semaphores provide a mechanism to protect critical sections of code, ensuring that they are executed atomically.
3. Dining Philosophers Problem Description: Philosophers sit around a circular table, thinking and eating. Each philosopher needs two forks (resources) to eat, but only one fork is placed between each pair. The problem is to design a protocol that prevents deadlock (all picking up one fork and waiting for the other) and starvation. Key Issue: Preventing circular wait and ensuring fair resource allocation. 4. Sleeping Barber Problem
Description: A barber sleeps if there are no customers. A customer entering wakes the barber. If all chairs are full, new customers leave. The system must manage barber availability and customer waiting. Key Issue: Coordinating service provision and customer flow.
In the context of operating systems, a monitor is a synchronization construct that simplifies concurrent access to shared resources by multiple processes or threads. It provides mutual exclusion, ensuring that only one process or thread can execute within the monitor's critical section at a time, preventing data corruption and race conditions. Monitors also offer mechanisms for process synchronization, allowing processes to wait for specific conditions to become true before proceeding. Key Features of Monitors: Mutual Exclusion: A monitor ensures that only one process or thread can access shared data or resources within the monitor at any given time. This prevents concurrent modifications that could lead to data inconsistencies. Encapsulation: Monitors encapsulate both shared data and the procedures that operate on that data. This bundling of data and operations promotes modularity and simplifies the design of concurrent systems. Synchronization:
Operations : In normal operation, a process must request a resource before using it and release it when finished, as shown below.
Methods of Handling Deadlocks Understanding how to handle deadlocks is vital for mastering operating systems. There are four approaches to dealing with deadlocks. 1. Deadlock Prevention 2. Deadlock avoidance (Banker's Algorithm) 3. Deadlock detection & recovery 4. Deadlock Ignorance (Ostrich Method) There are primarily four methods for handling deadlocks in operating systems: prevention, avoidance, detection and recovery, and ignorance (the ostrich method). Each method tackles the deadlock problem with a different approach, ranging from proactive measures to reactive solutions. Here's a breakdown of each method: 1. Deadlock Prevention: This method aims to prevent deadlocks by ensuring that at least one of the four necessary conditions for deadlock cannot occur. These conditions are mutual exclusion, hold and wait, no preemption, and circular wait. For example, one prevention method is to require processes to request all necessary resources at once, eliminating the "hold and wait" condition. 2. Deadlock Avoidance: