The Reader-Writer Problem is a classic synchronization problem that involves a shared resource,

such as a database, that can be accessed concurrently by multiple threads. The problem is divided
into two categories:

1. Readers: These threads can read from the shared resource, but they do not modify it.

2. Writers: These threads modify the shared resource, and while doing so, no other writer or
reader can access the resource.

Key Conditions for the Reader-Writer Problem:

 Multiple readers can read the shared resource at the same time, as long as no writer is
writing to it.

 Only one writer can access the shared resource at a time, and no readers can read while a
writer is writing.

 Writers should not be starved, and they must eventually get access to the resource.

Types of Reader-Writer Problems:

1. First-Come-First-Serve (FCFS) or Shared Preference: Prioritize readers over writers or vice

versa.

2. Writer Priority: Prioritize writers to avoid starvation of writers.

3. Reader Priority: Prioritize readers to avoid starvation of readers.

We will discuss a general solution for the Reader-Writer problem, focusing on fairness and
preventing starvation.

Solution Using Semaphores

The most common approach is to use semaphores for synchronization. Semaphores are signaling
mechanisms used to control access to shared resources. We can use them to handle the mutual
exclusion and coordination between readers and writers.

Data Structures:

1. mutex (binary semaphore): This semaphore is used to ensure mutual exclusion when
accessing shared variables. It prevents race conditions while modifying or reading the shared
resource.

2. rw_mutex (binary semaphore): This semaphore ensures mutual exclusion for the writers,
ensuring that only one writer can access the resource at a time.

3. read_count_mutex (binary semaphore): This semaphore is used to protect the read_count

variable, which tracks the number of active readers.

4. read_count (integer variable): This keeps track of how many readers are currently reading
the shared resource.

Algorithm Explanation:

Initialization:

 mutex = 1: The mutex semaphore starts as 1, allowing access to the critical section.
  rw_mutex = 1: The rw_mutex semaphore starts as 1, meaning only one writer can write at a
time.

 read_count_mutex = 1: Ensures mutual exclusion when updating read_count.

 read_count = 0: Initially, no readers are reading the shared resource.

Reader Process:

1. Acquire read_count_mutex: Before modifying the read_count, a reader acquires

read_count_mutex to avoid race conditions.

2. Increment read_count: Increase the count of active readers.

3. Release read_count_mutex: Release read_count_mutex to allow other readers to modify

the count.

4. Check if it is the first reader: If the current reader is the first one (i.e., read_count == 1),
acquire the rw_mutex to prevent writers from accessing the resource.

5. Read the shared resource: Perform the read operation on the shared resource.

6. Acquire read_count_mutex again: After reading, acquire read_count_mutex again.

7. Decrement read_count: Reduce the reader count.

8. Release read_count_mutex: Release read_count_mutex.

9. Check if it is the last reader: If the current reader is the last one (i.e., read_count == 0),
release rw_mutex to allow writers to write.

Writer Process:

1. Acquire rw_mutex: Before writing, a writer must acquire the rw_mutex semaphore to
ensure mutual exclusion with other writers.

2. Write to the shared resource: Perform the write operation on the shared resource.

3. Release rw_mutex: After writing, the writer releases rw_mutex to allow other writers or
readers to access the resource.

Code Implementation (Pseudocode):

# Initialization

mutex = Semaphore(1)

rw_mutex = Semaphore(1)

read_count_mutex = Semaphore(1)

read_count = 0

# Reader Process

def reader():
 global read_count

# Entry Section

wait(read_count_mutex) # Acquire read_count_mutex

read_count += 1 # Increment read count

if read_count == 1:

wait(rw_mutex) # First reader locks the resource for reading

signal(read_count_mutex) # Release read_count_mutex

# Critical Section (Reading)

# Read shared resource

# Exit Section

wait(read_count_mutex) # Acquire read_count_mutex

read_count -= 1 # Decrement read count

if read_count == 0:

signal(rw_mutex) # Last reader releases rw_mutex for writers

signal(read_count_mutex) # Release read_count_mutex

# Writer Process

def writer():

# Entry Section

wait(rw_mutex) # Acquire rw_mutex (only one writer can write)

# Critical Section (Writing)

# Write to shared resource

# Exit Section

signal(rw_mutex) # Release rw_mutex for other writers/readers

Explanation of the Solution:

1. Readers:
 o A reader process first increments the read_count and checks if it is the first reader. If
so, it locks the rw_mutex to prevent writers from accessing the resource.

o After reading, it decrements read_count. If it is the last reader, it releases rw_mutex

to allow writers to access the resource.

2. Writers:

o A writer process acquires the rw_mutex semaphore, ensuring that no other writer or
reader is accessing the resource.

o After writing, the writer releases the rw_mutex semaphore to allow other processes
to access the resource.

Key Points:

1. Mutual Exclusion: Ensures that only one writer or one group of readers can access the
resource at any given time.

2. Starvation Avoidance: The solution ensures that neither readers nor writers are starved. The
priority can be adjusted based on which process should be prioritized.

3. Concurrency: Multiple readers can access the shared resource concurrently, but only one
writer can write at a time.