Scribd
Upload
1K views

Classical Problems of Synchronization

The document discusses classical synchronization problems in operating systems, including the Bounded-Buffer, Readers-Writers, and Dining-Philosophers problems, highlighting their significance in managing concurrent processes. It explains the synchronization issues that arise in each scenario and provides solutions using semaphores and mutexes to ensure safe interactions. Additionally, it covers synchronization mechanisms in various operating systems like Windows and Linux, as well as alternative approaches to concurrency management.

Uploaded by

Hassan ali Sayed
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
1K views

Classical Problems of Synchronization

The document discusses classical synchronization problems in operating systems, including the Bounded-Buffer, Readers-Writers, and Dining-Philosophers problems, highlighting their significance in managing concurrent processes. It explains the synchronization issues that arise in each scenario and provides solutions using semaphores and mutexes to ensure safe interactions. Additionally, it covers synchronization mechanisms in various operating systems like Windows and Linux, as well as alternative approaches to concurrency management.

Uploaded by

Hassan ali Sayed
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 8

Classical Problems of Synchronization

Synchronization in operating systems is a crucial concept that ensures correct execution of


concurrent processes while avoiding conflicts, race conditions, and deadlocks. Several
classical synchronization problems are used to test newly proposed synchronization
schemes:
1. Bounded-Buffer (Producer-Consumer) Problem
2. Readers-Writers Problem
3. Dining-Philosophers Problem

Each of these problems represents a real-world concurrency issue and is solved using
synchronization mechanisms such as semaphores, mutexes, and condition variables.

Bounded-Buffer (Producer-Consumer) Problem


The Bounded-Buffer Problem is a fundamental example of concurrent access to a shared
resource. First introduced by Edsger W. Dijkstra in 1965, it models a scenario where
multiple producers generate data and store it in a shared buffer, while multiple consumers
retrieve and process the data.

Problem Description
 A shared buffer of fixed size (N) is used for communication between producers and
consumers.
 Producers add data to the buffer but must wait if the buffer is full.
 Consumers remove data from the buffer but must wait if the buffer is empty.

Synchronization Issues
Without proper synchronization, the following problems can occur:
1. Producers write to a full buffer, causing data loss.
2. Multiple producers write to the same slot, leading to corruption.
3. Consumers read from an empty buffer, leading to incorrect behavior.
4. Multiple consumers read from the same slot, leading to data inconsistency.
5. A consumer reads a slot before a producer has finished writing to it, leading to
partial data consumption.
Solution Using Semaphores
To ensure synchronization, we use:
 Mutex (Binary Semaphore): Ensures exclusive access to the buffer.
 Full (Counting Semaphore): Tracks the number of occupied slots.
 Empty (Counting Semaphore): Tracks the number of empty slots.

Initialization
 mutex = 1 → Allows exclusive access to the buffer.
 full = 0 → No items in the buffer initially.
 empty = N → All slots are available at the beginning.

Producer Process

Producer()
{
wait(empty); // Check if space is available
wait(mutex); // Lock buffer
// Add item to buffer
signal(mutex); // Unlock buffer
signal(full); // Increase count of occupied slots
}

Consumer Process

Consumer()
{
wait(full); // Check if any item is available
wait(mutex); // Lock buffer
// Remove item from buffer
signal(mutex); // Unlock buffer
signal(empty); // Increase count of empty slots
}

This ensures safe producer-consumer interactions.


Readers-Writers Problem
The Readers-Writers Problem involves multiple processes accessing a shared resource:
 Readers: Only read data (do not modify it).
 Writers: Can read and modify data.

Problem Description
 Multiple readers can read at the same time without conflicts.
 A writer must have exclusive access to the resource (no other readers or writers
should access it).

Synchronization Issues
1. Multiple writers modifying data simultaneously can lead to corruption.
2. Readers reading while a writer is modifying data can cause inconsistencies.
3. Starvation occurs when either readers or writers are indefinitely blocked.
Solution Using Semaphores
To ensure synchronization, we use:
 Mutex (Binary Semaphore): Provides mutual exclusion for modifying the readcount.
 wrt (Binary Semaphore): Ensures only one writer at a time.
 readcount (Integer): Keeps track of the number of active readers.

Initialization
 mutex = 1 → Controls access to readcount.
 wrt = 1 → Controls access to the resource.
 readcount = 0 → No readers initially.

 Writer Process
Writer()
{
wait(wrt); // Ensure exclusive access
// Perform writing
signal(wrt); // Release access
}
 Reader Process

Reader()
{
wait(mutex); // Lock `readcount`
readcount++;
if (readcount == 1) // First reader blocks writers
wait(wrt);
signal(mutex); // Unlock `readcount`

// Perform reading

wait(mutex); // Lock `readcount`


readcount--;
if (readcount == 0) // Last reader unblocks writers
signal(wrt);
signal(mutex); // Unlock `readcount`
}

This ensures proper reader-writer coordination.


Dining-Philosophers Problem
The Dining-Philosophers Problem models resource allocation among multiple processes
that need multiple resources to proceed.

Problem Description
 N philosophers sit at a circular table with N chopsticks (one between each pair).
 Each philosopher thinks and eats in cycles.
 To eat, a philosopher needs two chopsticks.
 They must pick one at a time, leading to a potential deadlock.

Synchronization Issues
1. Deadlock occurs if every philosopher picks up their left chopstick and waits for the
right one.
2. Starvation occurs if some philosophers never get both chopsticks.
3. Concurrency Issues arise if two philosophers pick up the same chopstick.

Solution Using Semaphores


To synchronize:
 chopstick[N] (Binary Semaphore) → One per chopstick, initialized to 1.
 Philosopher Process
Philosopher(i)
{
wait(chopstick[i]); // Pick left chopstick
wait(chopstick[(i+1)%N]); // Pick right chopstick
// Eat
signal(chopstick[i]); // Release left chopstick
signal(chopstick[(i+1)%N]); // Release right chopstick
// Think
}

Alternative Solutions to Avoid Deadlock


1. Limit philosophers to (N-1) eating at once.
2. Allow picking up both chopsticks only when both are available.
3. Use asymmetric behavior: Some pick left first, others pick right first.
Kernel Synchronization
Operating systems provide synchronization mechanisms to prevent race conditions.
Windows
 Uses interrupt masking to protect global resources on uniprocessor systems.
 Spinlocks are used in multiprocessor systems for busy-waiting.
 Dispatcher objects provide synchronization via:
o Mutexes
o Semaphores
o Events
o Timers

Linux
 Before kernel 2.6: Used interrupt disabling.
 After kernel 2.6: Fully preemptive, using:
o Semaphores
o Atomic integers
o Spinlocks
o Reader-writer locks

POSIX Synchronization
 Mutex locks: Provides mutual exclusion.
 Semaphores:
o Named: Used between unrelated processes.
o Unnamed: Used within the same process.
 Condition variables: Used for signaling between threads.

Java Synchronization
Java provides:
 Monitors: Implicit locks using synchronized keyword.
 Reentrant Locks: Explicit locks with flexibility.
 Semaphores: Controls access to resources.
 Condition Variables: Enables inter-thread communication.
Alternative Approaches
 Transactional Memory: Allows atomic memory transactions.
 OpenMP: Parallel programming API.
 Functional Programming: Eliminates side effects for better concurrency

You might also like