Reader-Writer Problem in Operating System with Code

In concurrent programming and operating systems, the Readers–Writers Problem is a classic synchronization problem that arises when multiple processes share the same resource such as a file, database, or memory location.

Some processes act as readers, meaning they only need to view the data without making any changes. Others are writers, which modify or update the data. While multiple readers can safely read the resource at the same time, the presence of even one writer requires exclusive access to prevent data inconsistency or corruption.

The main goal of the Readers–Writers Problem is to coordinate access so that:

• Writers have exclusive control during updates.
• Readers can share the resource when no writer is active.
• Conflicts, race conditions, and data corruption are avoided.

This problem forms the foundation for many real-world applications like database systems, shared document editing, and file servers, where proper synchronization is essential for consistency and reliability.

What is Readers–Writers Problem?

The Readers–Writers Problem is a classic synchronization problem in operating systems and concurrent programming.
It deals with the coordination between multiple processes (or threads) that share a common resource such as a file, database, or memory location.

In this problem:

• Readers → can only read the shared resource, without modifying it.
• Writers → can modify the shared resource, and this may change what readers see.

The main challenge is to ensure data consistency and prevent conflicts while allowing maximum concurrency.

The Rules

1. Multiple readers can read simultaneously without problems (reading does not change the data).
2. Only one writer can write at a time, and no readers can read while writing (to avoid reading inconsistent data).
3. If a writer is writing, all other writers and readers must wait.

The Main Problem

Imagine a file that is shared between processes:

• If two writers write at the same time → data corruption may occur.
• If a writer writes while a reader reads → the reader might get partially updated or incorrect data.
• If many readers read at the same time → no problem, as long as no writer is active.

The difficulty lies in managing who gets priority:

• Should readers wait for writers to finish?
• Should writers wait until all readers are done?
• Should there be fairness between them?

Real-World Analogy

Think of a library:

• Many people can read the same book in the reading room at the same time (readers).
• If someone wants to edit or replace the book (writer), the reading room must be cleared first, no one can read until the update is done.
• After the update, multiple readers can again read together.

Types of Readers–Writers Problems

There are multiple variations:

1. First Readers–Writers Problem (Reader Priority)
   • Readers are given priority → A writer might starve if readers keep coming.
2. Second Readers–Writers Problem (Writer Priority)
   • Writers are given priority → A reader might starve if writers keep coming.
3. Third Readers–Writers Problem (Fairness / No Starvation)
   • Readers and writers are treated equally → Scheduling ensures fairness.

Synchronization Using Semaphores

We use two semaphores and a reader counter:

• rc → reader count (tracks how many readers are currently reading).
• mutex → semaphore to protect updates to rc (so two readers don’t change rc at the same time).
• wrt → semaphore to control writer access (ensures mutual exclusion for writers).

Pseudocode: Reader Process

// Entry Section for Reader
wait(mutex);       // Lock to update reader count
rc++;
if (rc == 1)       // First reader locks the resource for writers
    wait(wrt);
signal(mutex);     // Unlock reader count

// Critical Section (Read)
READ_FROM_OBJECT();

// Exit Section for Reader
wait(mutex);
rc--;
if (rc == 0)       // Last reader releases the resource
    signal(wrt);
signal(mutex);

Pseudocode: Writer Process

// Entry Section for Writer
wait(wrt);         // Lock resource for writing

// Critical Section (Write)
WRITE_TO_OBJECT();

// Exit Section for Writer
signal(wrt);       // Unlock resource

Key Points to Remember

• Readers can share the resource with other readers, but writers always need exclusive access.
• Semaphores help coordinate access and prevent race conditions.
• Priority choice (reader or writer) affects system performance and fairness.
• This problem applies to files, databases, memory, and even network resources in real systems.