ReadersWriters Problem | Writers Preference Solution (original) (raw)

Last Updated : 30 Aug, 2025

The Readers-Writers Problem is a classic synchronization challenge in operating systems and concurrent programming. It describes a scenario where multiple threads or processes need to access a shared resource (like a database or file) simultaneously. Some of these threads are "readers" (they only read the data), and others are "writers" (they modify the data). The goal is to allow as much concurrent access as possible while preserving data consistency.

In simpler terms, the rules of this problem are:

• **Readers: Any number of reader threads can read the shared resource at the same time, as reading does not change data. Multiple readers cause no conflicts, so they should be allowed to work in parallel.
• **Writers: Only one writer thread can access the shared resource at a time. Moreover, when a writer is writing, no readers should be reading. This exclusivity is essential because if a writer modifies data while others are reading, it could lead to corrupted or inconsistent data.

This problem is important because it models real-world situations like managing a database with many simultaneous users. We want to maximize efficiency by letting readers run in parallel, but we must prevent conflicts with writers.

Read more about Reader-Writer Problem

There are two main preference solutions for the Readers-Writers problem: **Readers Preference, prioritizing readers (potentially starving writers), and **Writers Preference, prioritizing writers (potentially starving readers).

The Writers Preference Solution

There are multiple variations of the readers-writers problem, depending on who gets priority when both readers and writers are waiting. In the Writers Preference solution (also known as writers-priority), the system is designed to prioritize writers over readers.

The motivation for this approach comes from a drawback in the simplest (readers-preference) solution:

• If readers keep arriving continuously, a waiting writer might never get a turn (this is called writer starvation). To avoid this, the writers-preference strategy ensures that once a writer is waiting to access the shared resource, no new readers are allowed to start reading.
• In other words, as soon as a writer signals that it needs to write, it will get to do so as soon as possible even if readers are also waiting.

How Writers Preference Works

• If there are no writers waiting or writing, multiple readers can proceed simultaneously as usual.
• If a writer wants to write, it will indicate its presence (e.g. by entering a queue). From that moment, no new reader is allowed to start reading until that writer gets to write. Readers that were already reading can finish, but newcomers must wait.
• When the resource becomes free (e.g. all active readers finish), the waiting writer is given access next, before any of the waiting readers. This guarantees the writer isn't stuck waiting behind an endless stream of readers.
• Only one writer can write at a time. If multiple writers are waiting, they will each get a turn one by one (with writers essentially forming a queue). During this period, readers will wait so that the writers can clear out quickly.
• Once there are no writers left waiting, readers may resume accessing the resource.

Implementation of Writers Preference Solution

To implement Writers Preference Solution we need to enforce the rule that no new reader may start when a writer is waiting. A common strategy is to use semaphores (or similar locking primitives) to control access.

**Following steps should be followed to implement Writers Preference Solution:

• Maintain a count of active readers (read_count) and a count of waiting writers (write_count). These help track how many threads are currently reading or intending to write.
• Use a semaphore resource to control access to the shared resource. Resource is acquired in write mode by writers (exclusive access), or by the first reader and held until the last reader finishes (allowing shared access among readers).
• Use another semaphore as a gate to block readers when a writer is waiting. Readers must "check in" through this semaphore before they can proceed. If a writer has signaled its intent to write (locking this gate), new readers will wait at this step. This is key to giving writers priority.
• Protect the counters with their own small mutexes (e.g. rmutex for read_count and wmutex for write_count) to avoid race conditions when updating these shared variables.

semaphore resource = 1; // actual shared data
semaphore readTry = 1; // gate that writers can close to block new readers
semaphore rmutex = 1; // protects read_count
semaphore wmutex = 1; // protects write_count
semaphore serviceQueue = 1; // turnstile to serialize arrival across readers & writers
int read_count = 0;
int write_count = 0;

// -------- Reader --------
void reader() {
// Get in the global line so we can't jump ahead of a waiting writer
wait(serviceQueue);
wait(readTry); // blocked if a writer has closed the gate
signal(serviceQueue); // let next arrival line up

wait(rmutex);
read_count++;
if (read_count == 1) wait(resource); // first reader locks the resource
signal(rmutex);

signal(readTry); // pass gate along (a queued writer will get it next)

// ---- Critical Section (read) ----
// ... read shared data ...

wait(rmutex);
read_count--;
if (read_count == 0) signal(resource); // last reader frees the resource
signal(rmutex);
}

// -------- Writer --------
void writer() {
wait(wmutex);
write_count++;
if (write_count == 1) wait(readTry); // first waiting writer closes the reader gate
signal(wmutex);

// Get in the same global line as readers so they can't cut ahead
wait(serviceQueue);
wait(resource); // exclusive access
signal(serviceQueue);

// ---- Critical Section (write) ----
// ... write shared data ...

signal(resource);

wait(wmutex);
write_count--;
if (write_count == 0) signal(readTry); // reopen gate for readers
signal(wmutex);
}

Limitations of the Writers Preference Solution

While the writers-preference solution effectively prevents writer starvation by ensuring that waiting writers eventually gain priority access, it introduces certain trade-offs:

• **Reader Starvation: If writers frequently arrive, readers may be continuously delayed, potentially never getting access to read.
• **Reduced Parallelism: By prioritizing writers, the concurrent advantage of multiple readers accessing data simultaneously can be reduced, lowering overall throughput.
• **Complexity: Ensuring writers receive priority access typically involves additional synchronization logic, making the implementation more complex compared to simpler solutions.