Skip to main content

Command Palette

Search for a command to run...

Readers-Writers Problem

Updated
3 min read
J

I am Jyotiprakash, a deeply driven computer systems engineer, software developer, teacher, and philosopher. With a decade of professional experience, I have contributed to various cutting-edge software products in network security, mobile apps, and healthcare software at renowned companies like Oracle, Yahoo, and Epic. My academic journey has taken me to prestigious institutions such as the University of Wisconsin-Madison and BITS Pilani in India, where I consistently ranked among the top of my class.

At my core, I am a computer enthusiast with a profound interest in understanding the intricacies of computer programming. My skills are not limited to application programming in Java; I have also delved deeply into computer hardware, learning about various architectures, low-level assembly programming, Linux kernel implementation, and writing device drivers. The contributions of Linus Torvalds, Ken Thompson, and Dennis Ritchie—who revolutionized the computer industry—inspire me. I believe that real contributions to computer science are made by mastering all levels of abstraction and understanding systems inside out.

In addition to my professional pursuits, I am passionate about teaching and sharing knowledge. I have spent two years as a teaching assistant at UW Madison, where I taught complex concepts in operating systems, computer graphics, and data structures to both graduate and undergraduate students. Currently, I am an assistant professor at KIIT, Bhubaneswar, where I continue to teach computer science to undergraduate and graduate students. I am also working on writing a few free books on systems programming, as I believe in freely sharing knowledge to empower others.

The Readers-Writers Problem is a classic example of a synchronization problem faced in computing, specifically in the context of shared resources. The problem can be explained as follows:

  • There are a shared resource (like a file or a database) and multiple processes that need access to this resource.

  • There are two kinds of processes: readers and writers.

  • Readers only read the data from the resource and do not perform any updates.

  • Writers can read and modify the data.

  • The critical constraint is that while a writer is writing to the resource, no other writer or reader should be able to access the resource. This is to prevent data inconsistency.

  • However, multiple readers can simultaneously read the resource without any issues, as long as there is no writer writing to it.

Solving Using Mutexes and Semaphores

We use mutexes and semaphores to synchronize access to the resource. A mutex ensures mutual exclusion, i.e., only one process can access the critical section of code at a time. Semaphores are used to control access, specifically a binary semaphore (which acts like a mutex) and a counting semaphore.

The solution involves using two semaphores:

  1. A binary semaphore (often referred to as a write_lock) for writers to ensure mutual exclusion while writing.

  2. A counting semaphore to keep track of the number of readers currently accessing the resource.

Pseudo Code

Writer Pseudo Code

do {
    wait(write_lock);        // Acquire the write lock
    // Perform writing...
    signal(write_lock);      // Release the write lock
} while (true);

Reader Pseudo Code

do {
    wait(mutex);             // Acquire mutex to update reader count
    read_count++;
    if (read_count == 1) {
        wait(write_lock);    // If this is the first reader, lock the write lock
    }
    signal(mutex);           // Release mutex

    // Perform reading...

    wait(mutex);             // Acquire mutex to update reader count
    read_count--;
    if (read_count == 0) {
        signal(write_lock);  // If this is the last reader, release the write lock
    }
    signal(mutex);           // Release mutex
} while (true);

Explanation

  • Writer Process:

    • The writer acquires the write_lock before starting to write. This ensures that no other writer or reader can access the resource while writing is in progress.

    • After writing, it releases the write_lock, allowing other processes (readers or writers) to access the resource.

  • Reader Process:

    • Each reader process acquires the mutex to safely increment the count of readers (read_count).

    • If it's the first reader, it also acquires the write_lock to prevent writers from accessing the resource while reading is in progress.

    • After reading, the reader decrements read_count and checks if it's the last reader. If it is, it releases the write_lock, allowing writers to access the resource.

    • The mutex is used to ensure that the update of read_count is mutually exclusive.

This solution ensures that writers have exclusive access to the resource while writing, and multiple readers can read concurrently, as long as no writer is writing. The key is to prevent a writer from writing when there are readers reading and vice versa.

More from this blog

Jyotiprakash's Blog

251 posts

I'm Jyotiprakash, a software dev and professor at KIIT, with expertise in system programming.