Readers-Writers Problem | Operating System - Computer Science Engineering (CSE) PDF Download

Introduction and Readers Preference Solution

Consider a situation where we have a file shared between many people.

• If one of the people tries editing the file, no other person should be reading or writing at the same time, otherwise changes will not be visible to him/her.
• However if some person is reading the file, then others may read it at the same time.

Precisely in OS we call this situation as the readers-writers problem

Problem parameters:

• One set of data is shared among a number of processes
• Once a writer is ready, it performs its write. Only one writer may write at a time
• If a process is writing, no other process can read it
• If at least one reader is reading, no other process can write
• Readers may not write and only read

Solution when Reader has the Priority over Writer
Here priority means, no reader should wait if the share is currently opened for reading.
Three variables are used: mutex, wrt, readcnt to implement solution

1. semaphore mutex, wrt; // semaphore mutex is used to ensure mutual exclusion when readcnt is updated i.e. when any reader enters or exit from the critical section and semaphore wrt is used by both readers and writers
2. int readcnt;  //    readcnt tells the number of processes performing read in the critical section, initially 0

Functions for sempahore:

• wait() : decrements the semaphore value.
• signal() : increments the semaphore value.

Writer process:

1. Writer requests the entry to critical section.
2. If allowed i.e. wait() gives a true value, it enters and performs the write. If not allowed, it keeps on waiting.
3. It exits the critical section.

// Program
do {
    // writer requests for critical section
    wait(wrt);  
    // performs the write
    // leaves the critical section
    signal(wrt);
} while(true);

Reader process:

1. Reader requests the entry to critical section.
2. If allowed:
   • it increments the count of number of readers inside the critical section. If this reader is the first reader entering, it locks the wrt semaphore to restrict the entry of writers if any reader is inside.
   • It then, signals mutex as any other reader is allowed to enter while others are already reading.
   • After performing reading, it exits the critical section. When exiting, it checks if no more reader is inside, it signals the semaphore “wrt” as now, writer can enter the critical section.
3. If not allowed, it keeps on waiting.
   //Program
   do {  

      // Reader wants to enter the critical section
      wait(mutex);
      // The number of readers has now increased by 1
      readcnt++;                          
      // there is atleast one reader in the critical section
      // this ensure no writer can enter if there is even one reader
      // thus we give preference to readers here
      if (readcnt==1)    
         wait(wrt);                    
      // other readers can enter while this current reader is inside
      // the critical section
      signal(mutex);                  
      // current reader performs reading here
      wait(mutex);   // a reader wants to leave
      readcnt--;
      // that is, no reader is left in the critical section,
      if (readcnt == 0)
          signal(wrt);         // writers can enter
      signal(mutex); // reader leaves
   } while(true);

Thus, the semaphore ‘wrt‘ is queued on both readers and writers in a manner such that preference is given to readers if writers are also there. Thus, no reader is waiting simply because a writer has requested to enter the critical section.

Reader-Writers solution using Monitors

Considering a shared Database our objectives are:

• Readers can access database only when there are no writers.
• Writers can access database only when there are no readers or writers.
• Only one thread can manipulate the state variables at a time.

Basic structure of a solution

• Reader()
  1. Wait until no writers
  2. Access database
  3. Check out – wake up a waiting writer
• Writer()
  1. Wait until no active readers or writers
  2. Access database
  3. Check out – wake up waiting readers or writer

Now let’s suppose that a writer is active and a mixture of readers and writers now show up.

Who should get in next?
Or suppose that a writer is waiting and an endless of stream of readers keep showing up.

Would it be fair for them to become active?
So we’ll implement a kind of back-and-forth form of fairness:

• Once a reader is waiting, readers will get in next.
• If a writer is waiting, one writer will get in next.

Implementation of the solution using monitors:

1. The methods should be executed with mutual exclusion i.e. At each point in time, at most one thread may be executing any of its methods.
2. Monitors also provide a mechanism for threads to temporarily give up exclusive access, in order to wait for some condition to be met, before regaining exclusive access and resuming their task.
3. Monitors also have a mechanism for signaling other threads that such conditions have been met.
4. So in this implementation only mutual exclusion is not enough. Threads attempting an operation may need to wait until some assertion P holds true.
5. While a thread is waiting upon a condition variable, that thread is not considered to occupy the monitor, and so other threads may enter the monitor to change the monitor’s state.