Readers-Writers Problem
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:
A binary semaphore (often referred to as a
write_lock) for writers to ensure mutual exclusion while writing.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_lockbefore 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
mutexto safely increment the count of readers (read_count).If it's the first reader, it also acquires the
write_lockto prevent writers from accessing the resource while reading is in progress.After reading, the reader decrements
read_countand checks if it's the last reader. If it is, it releases thewrite_lock, allowing writers to access the resource.The
mutexis used to ensure that the update ofread_countis 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.