Readers-Writers Problem | Writers Preference Solution

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; // Controls access to the shared resource (1 = free, 0 = locked)
semaphore readTry = 1; // Semaphore to allow or block readers (writer will lock this to get priority)
semaphore rmutex = 1; // Mutex for protecting read_count
semaphore wmutex = 1; // Mutex for protecting write_count
int read_count = 0; // Number of readers currently reading
int write_count = 0; // Number of writers waiting or in critical section

void reader() {
// Entry Section (attempt to enter read)
wait(readTry); // Attempt to enter the "readers gate". If a writer has locked this, reader waits here.
wait(rmutex); // Lock rmutex to safely update read_count
read_count++;
if (read_count == 1) {
wait(resource); // If this is the first reader, lock the resource for readers (blocks writers).
}

signal(rmutex);
signal(readTry); // Release the gate so others can try to enter (allows other readers or a waiting writer to proceed accordingly)

// Critical Section (Reading happens here)
// ... (read the shared data) ...
// Exit Section (finished reading)

wait(rmutex); // Lock rmutex to update read_count safely
read_count--;
if (read_count == 0) {
signal(resource); // If this was the last reader, release the resource lock (so writers can use it)
}
signal(rmutex);
}

void writer() {
// Entry Section (attempt to enter write)
wait(wmutex); // Lock wmutex to update write_count safely
write_count++;
if (write_count == 1) {
wait(readTry); // If this is the first waiting writer, lock the readers gate.
// (This blocks new readers from entering while writers are waiting.)
}

signal(wmutex);
wait(resource); // Lock the resource for exclusive access to write

// Critical Section (Writing happens here)
// ... (write to the shared data) ...
signal(resource); // Release the resource after writing is done
// Exit Section (finished writing)

wait(wmutex);
write_count--;
if (write_count == 0) {
signal(readTry); // If this was the last writer, open the gate for readers again.
}
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.