Get free ebooK with 50 must do coding Question for Product Based Companies solved
Fill the details & get ebook over email
Thank You!
We have sent the Ebook on 50 Must Do Coding Questions for Product Based Companies Solved over your email. All the best!

Reader Writer Problem in OS

Last Updated on March 15, 2023 by Prepbytes

Reader Writer Problem is one of the famous operating system problems related to synchronization where multiple processes can be found reading or writing on the same shared resource at the same time synchronously.

How the Reader-Writer Problem is OS Handled

In order to handle the problem, it must be ensured that no concurrent processes cause any form of data inconsistency in the operating system. The reader-writer problem in os can be assumed as follows:-

There are multiple processes that can be either readers and writers with a shared resource between them, let us suppose it as a file or a database. In case there are two processes with both trying to access the resource simultaneously at the same instance. Although it does not matter how many readers can access it simultaneously, it must be kept in mind that only one writer can write it at a time.

There are several algorithms that are designed to curb this problem and among the many algorithms available, we are going to use one to solve the reader-writer problem in os.

Various Cases of Reader-Writer Problem

There are certain cases that I must look forward to understanding the reader-writer problem in os and how it impacts the data inconsistency problem that must be avoided.

Case One
Two processes cannot be allowed to write into shared data parallelly thus they must wait to get access to write into it.

Case Two
Even if one process is writing on data and the other is reading then also they cannot be allowed to have the access to shared resources for the reason that a reader will be reading an incomplete value in this case.

Case Three
The other similar scenario where one process is reading from the data and another writing on it, on the shared resource, it cannot be allowed. Because the writer updates some data that is not available to the reader. The solution being that the writer completes successfully and gives access.

Case Four
In the case that both processes are reading the data then sharing of resources among both the processes will be allowed as it is a case free from any such anomaly because reading does not modify the pre-existing data.

The Solution to the Problem

In order to solve the problem, we maintain three variables, namely, mutex, semaphore, and readCount.

Mutex makes the process to release and acquire a lock when the readCount is being updated. The lock is acquired when the readCount is updated and decremented back after it has done performing the operation. The writer waits for the semaphore until it is its turn to write and increments for other processes to write.

The idea remains to use semaphores when a reader enters the critical section up until it exits the critical section such that no writer can enter in between as it can cause data inconsistency. A semaphore is used to prevent writers from accessing the resource while there are one or more readers accessing it.

Code:

The given code below is the code for the writer’s side.

while (TRUE) {
    // Wait on the "w" semaphore to acquire access to the resource
    wait(w);

    // Perform the necessary write operation(s) on the resource
    // ...

    // Signal the "w" semaphore to allow other writer processes to access the resource
    signal(w);
}

Explanation:
The above code implements a simple solution for the writer process where the writer waits for the "w" semaphore to become available and then performs the write operation on the resource. The writer then signals the "w" semaphore to allow other writer processes to access the resource. Note that the code is in an infinite loop, so the writer process will continuously wait for the "w" semaphore to become available and then perform the write operation.

Given below is the code for readers side:-

while (TRUE) { // Loop indefinitely
    // Acquire lock
    wait(m); // Wait for the mutex semaphore to be available

    readCount++; // Increment the number of processes doing the read operation
    if (readCount == 1) {
        wait(w); // If this is the first reader, wait for writer semaphore to be available
    }

    // Release lock
    signal(m); // Signal mutex semaphore to allow other processes to access the critical section

    /* Perform the reading operation */
    // Here we assume that the necessary code to read from the resource has been added

    // Acquire lock
    wait(m); // Wait for the mutex semaphore to be available

    readCount--; // Decrement the number of processes doing the read operation
    if (readCount == 0) {
        signal(w); // If this is the last reader, signal writer semaphore to allow writer processes to access the critical section
    }

    // Release lock
    signal(m); // Signal mutex semaphore to allow other processes to access the critical section
}

Explanation:
The code uses three variables: "mutex" to ensure mutual exclusion while updating the "readCount" variable, "w" semaphore to ensure that no writer can access the critical section when a reader is accessing it, and "readCount" to keep track of the number of processes performing the read operation. In the code, each process first acquires the "mutex" lock before updating the "readCount" variable. If this is the first reader process to access the resource, it waits for the "w" semaphore to become available, which means that no writer process is currently accessing the resource.

After performing the read operation, the process again acquires the "mutex" lock and decrements the "readCount" variable. If this is the last reader process accessing the resource, it signals the "w" semaphore to allow writer processes to access the critical section.

Conclusion
In this article, we studied what is reader writer problem in os and what are the different cases involved in this problem. We studied what mutex and semaphores are and throughout the article, we also studied how we can solve this problem along with its code.

We hope you liked this article and hope to see you again at PrepBytes.

Frequently Asked Questions

1. What is the reader-writer problem in operating systems?
The reader-writer problem is a classic synchronization problem in operating systems where multiple processes require access to a shared resource. In this problem, some processes may only read the resource while others may write to it. The goal is to ensure that multiple reader processes can access the resource simultaneously, but only one writer process can access the resource at a time to avoid data inconsistency.

2. What is a solution to the reader-writer problem?
One possible solution to the reader-writer problem is to use a mutex lock and a semaphore. The mutex lock ensures mutual exclusion while updating a variable that keeps track of the number of processes performing the read operation. The semaphore ensures that no writer can access the critical section while a reader is accessing it. The solution works by allowing multiple reader processes to access the critical section simultaneously, but only one writer process can access it at a time. The writer process waits for the semaphore to become available and then writes to the resource while all reader processes wait. After the writer process releases the semaphore, all reader processes can access the resource simultaneously.

3. What is the difference between readers and writers in the reader-writer problem?
In the reader-writer problem, reader processes only need to read from the shared resource, while writer processes need to write to it. Readers are allowed to access the resource simultaneously, while writers must have exclusive access to the resource to avoid data inconsistency.

4. What are the potential issues with the solution to the reader-writer problem?
One potential issue with the solution to the reader-writer problem is that it may lead to starvation. If a writer process continually requests access to the resource, it may never get the chance to access it if there are always reader processes accessing it.

Leave a Reply

Your email address will not be published. Required fields are marked *