PROJECT BASED LEARNING REPORT ON
READERS’S AND WRITER’S PROBLEM
BACHELOR OF TECHNOLOGY
in
COMPUTER SCIENCE AND ENGINEERING (DATA SCIENCE)
by
SHREYAS PARANGI (23R11A67D8)
ERUMALLA RAJESH (23R11A67B0)
BHUKYA MAHESH (23R11A67A5)
Under the esteemed guidance of
Dr. L. Kiran Kumar Reddy
Professor
Department of CSE (DATA SCIENCE)
Geethanjali College of Engineering and Technology
(UGC Autonomous)
(Affiliated to J.N.T.U.H, Approved by AICTE, New Delhi) Cheeryal (V),
Keesara (M), [Link].-501 301.
June-2025
Geethanjali College of Engineering & Technology
(UGC Autonomous)
(Affiliated to JNTUH, Approved by AICTE, New Delhi) Cheeryal (V),
Keesara(M), Medchal Dist.-501 301.
DEPARTMENT OF CSE (DATA SCIENCE)
CERTIFICATE
This is to certify that the B. Tech Project Based Learning report entitled “READER’S AND
WRITER’S PROBLEM USING MONITORS” is a bonafide work done by P. Shreyas
(23R11A67D8), E. Rajesh (23R11A67B0), B. Mahesh (23R11A67A5), in partial fulfillment of the
requirement of the award for the degree of Bachelor of Technology in “CSE (DATA SCIENCE)” from
Jawaharlal Nehru Technological University, Hyderabad during the year 2024-2025.
Internal Guide HOD – DS
Dr. L. Kiran Kumar Reddy Dr. B. Srinivasa Rao
Professor Professor
Geethanjali College of Engineering & Technology
(UGC Autonomous)
(Affiliated to JNTUH Approved by AICTE, New Delhi) Cheeryal (V),
Keesara(M), Medchal Dist.-501 301.
DEPARTMENT OF CSE (DATA SCIENCE)
DECLARATION BY THE CANDIDATE
We, P. SHREYAS, E. RAJESH, B. MAHESH bearing Roll Nos. 23R11A67D8, 23R11A67B0, 23R11A67A5
hereby declare that the project report entitled “READER’S AND WRITER’S PROBLEM USING MONITORS”
is done under the guidance of Dr. L. Kiran Kumar Reddy, Professor, Department of Computer Science and
Engineering, Geethanjali College of Engineering and Technology, is submitted in partial fulfillment of the
requirements for the award of the degree of Bachelor of Technology in CSE (DATA SCIENCE).
This is a record of bonafide work carried out by us in Geethanjali College of Engineering and Technology and
the results embodied in this project have not been reproduced or copied from any source. The results embodied in
this project report have not been submitted to any other University or Institute for the award of any other degree or
diploma.
[Link](23R11A67D8),
[Link] (23R11A67B0),
B. Mahesh (23R11A67A5),
Department of CSE(DS),
Geethanjali College of Engineering and
Technology, Cheeryal
TABLE OF CONTENTS
CONTENTS: PAGE NO.
1. Abstract 2
2. Introduction 3
2.1 About the Project 3
3. System Analysis 5
3.1 Existing System 5
3.2 Proposed System 6
3.3 System Configuration 7
3.4 Scope of the Project 8
4. System Design 10
4.1 System Architecture 10
4.2 System Design 11
4.3 Modules Description 14
5. Implementation 17
5.1 Technologies Used 17
5.2 Sample Code 18
6. Output Screen 21
7. Conclusion 22
7.1 Conclusion 22
7.2 Future Enhancements 23
8. Bibliography 24
8.1 Website References 24
1
1. ABSTRACT
The Readers-Writers Problem is a fundamental synchronization issue in operating systems that
explores how concurrent processes interact with shared data. This project simulates the Readers-
Writers problem using Monitors, a high-level synchronization construct that ensures controlled
access to critical sections of code. In this scenario, multiple reader threads can access shared data
concurrently, provided no writer is writing, while writer threads require exclusive access to
maintain data consistency. This simulation is implemented in Java, utilizing monitor-like
constructs such as the synchronized keyword and inter-thread communication methods like
wait() and notify(). These mechanisms control access to a shared resource and enforce
synchronization rules so that no readers read during writing and no writers write during reading.
The monitor coordinates all access to the shared resource and facilitates communication between
threads through condition variables. The project offers a visual and practical understanding of
thread coordination by displaying which threads are reading, writing, or waiting at a given time.
This real-time simulation helps learners grasp core concepts of mutual exclusion, condition
synchronization, and concurrent thread execution. The project not only deepens theoretical
understanding of synchronization in operating systems but also strengthens programming skills
in multithreading and concurrency management using Java.
2
2. INTRODUCTION
2.1 ABOUT THE PROJECT
The “Readers and Writers Problem using Monitors” project introduces a software simulation
designed to demonstrate a classic synchronization problem in operating systems. This problem
highlights the need for proper coordination when multiple threads (or processes) access a shared
resource such as a file or database. In this scenario, multiple readers are allowed to access the
shared resource concurrently, while writers must have exclusive access to prevent data
inconsistency.
Synchronization Core:
o Utilizes the Monitor concept to manage access to the shared resource.
o Implements Java synchronization primitives such as synchronized, wait(), and notify() to
control the execution flow of threads.
Thread Interaction:
o Creates a multi-threaded environment where readers and writers operate simultaneously.
o Manages concurrent read access and exclusive write access to maintain consistency.
Modular Design:
o Separates logic into key components such as thread creation, access control, and monitor
behavior.
o Encourages clean, maintainable code through abstraction of synchronization logic.
Efficient Solution:
o Demonstrates the efficiency of monitor-based synchronization in solving concurrent access
problems.
o Prevents race conditions and ensures data integrity even with multiple concurrent threads.
3
Educational Value:
o Offers hands-on experience with thread synchronization using Java.
o Improves understanding of concurrency control, mutual exclusion, and condition
synchronization in operating systems.
This project encapsulates the essence of monitor-based synchronization in a practical
and visual manner, offering users an educational experience in understanding and
solving real-world concurrent access problems.
4
3. SYSTEM ANALYSIS
3.1 EXISTING SYSTEM
In traditional operating systems and multithreaded applications, synchronizing concurrent
access to shared resources is a critical challenge. In many basic implementations,
synchronization is handled using semaphores, mutexes, or locks, which require careful
management by the programmer to prevent race conditions, deadlocks, or resource
starvation. These low-level constructs provide essential functionality but can be error-prone
and complex to use, especially in large or scalable systems. For example, a naive
implementation of the Readers-Writers Problem using basic locks may allow writer
starvation (i.e., readers constantly prevent a writer from acquiring access), or it might suffer
from inefficient locking, where only one thread accesses the resource at a time even when
concurrent reads would be safe. Such issues can degrade performance and compromise data
consistency. Moreover, these systems often lack a clean abstraction for coordinating
multiple threads in a structured and readable way, making debugging and maintenance more
difficult. In summary, while existing synchronization mechanisms can address the Readers-
Writers Problem, they require meticulous attention to detail and can become difficult to
manage in complex systems.
5
3.2 PROPOSED SYSTEM
The proposed system introduces a more structured and safer approach to synchronization by
implementing the Readers-Writers Problem using Monitors in Java. A monitor
encapsulates synchronization logic within a shared object, allowing only one thread to
execute within it at any given time. It also uses condition variables to enable threads to wait
and be notified when it is safe to proceed. This design reduces the complexity of thread
synchronization and minimizes the risk of race conditions or deadlocks.
The monitor coordinates access such that:
o Multiple readers can read the shared resource concurrently if there is no active writer.
o A writer gets exclusive access, ensuring data consistency.
o Fairness mechanisms can be integrated to prevent starvation of either readers or
writers.
Java's synchronized methods and inter-thread communication methods (wait(), notify(),
notifyAll()) provide the necessary tools to implement this logic effectively. The system is
designed in a modular fashion, with separate classes and functions for thread creation,
monitor logic, and access control, which improves readability and maintainability.
Additionally, the project provides a visual simulation showing which threads are reading,
writing, or waiting at any moment. This makes it easier for learners to observe how monitor-
based synchronization works in practice and how different thread types interact under the
rules of mutual exclusion and condition synchronization. Overall, the proposed system not
only ensures correct synchronization but also serves as an educational tool for
understanding advanced concurrency concepts in operating systems through hands-on
implementation.
6
3.3 SYSTEM CONFIGURATION
3.3.1 Software Requirements
Operating System: Windows/Mac/Linux
IDE: Preferred IDE for Java development:
o IntelliJ IDEA
o Eclipse
o NetBeans
Programming Language: Java
Java Development Kit (JDK): Version 8 or above
Text Editor (Optional): VS Code, Sublime Text, or Notepad++
Version Control System (Optional): Git
3.3.2 Hardware Requirements:
CPU: Intel Core i3 / i5 / i7 / AMD Ryzen or equivalent (Quad Core recommended)
RAM: Minimum 8 GB
Storage: Sufficient space for Java project files (approximately 50 MB or more)
Display: Minimum resolution of 1024×768
7
3.4 SCOPE OF THE PROJECT
Concurrency Control:
o Simulates the classic Readers-Writers synchronization problem using Java threads
and monitors.
o Ensures that multiple readers can access the shared resource simultaneously while writers
gain exclusive access to maintain data consistency.
Monitor-Based Synchronization:
o Demonstrates the practical implementation of monitor constructs using Java’s
synchronized, wait(), and notify() mechanisms.
o Provides insight into condition synchronization and mutual exclusion handling in
concurrent systems.
Thread Management:
o Manages multiple reader and writer threads efficiently in a multithreaded environment.
o Controls thread execution flow to ensure fairness and prevent race conditions or
deadlocks.
User Understanding and Visualization:
o Offers a clear and interactive simulation of thread behavior—indicating which threads are
reading, writing, or waiting.
o Aids in understanding complex synchronization patterns through real-time output and
logs.
Educational Value:
o Helps students grasp the concepts of thread synchronization, operating system
8
concurrency problems, and monitor constructs.
o Strengthens programming skills by translating theoretical OS problems into runnable
Java code.
Scalability and Versatility:
o Can be scaled to support more threads, readers, or writers to simulate higher-load
scenarios.
o Adaptable for extending into other synchronization problems like Dining Philosophers,
Bounded Buffer, etc.
Stand-Alone Application:
o Functions as a stand-alone Java application, runnable on any system with JDK installed,
without requiring additional dependencies.
o Provides a simple command-line interface to observe thread execution and monitor
behavior directly.
Documentation and Modularity:
o Enhances code clarity and learning through well-documented logic and detailed inline
comments explaining synchronization steps
o Follows a modular design pattern, separating concerns such as thread creation, monitor
implementation, and shared resource access.
o Facilitates scalability and future enhancements, such as adding priority rules or fairness
policies for readers and writers.
9
4. SYSTEM DESIGN
4.1 SYSTEM ARCHITECTURE
10
4.2 SYSTEM DESIGN - USER INTERFACE DESIGN
o Provide a simple user interface (console-based or GUI) to simulate reader and writer
processes.
o Allow users to specify whether a new process is a Reader or a Writer.
o Visually or textually display current active readers/writers, waiting processes, and access
status.
o Display mutual exclusion control in action using monitor-like behaviour.
4.2.1 Monitor Logic Implementation:
o Use monitor constructs (or pseudocode resembling monitors) to manage synchronization.
o Define condition variables for managing reader and writer access.
o Implement wait() and signal() (or equivalents) for coordinating reader/writer access.
o Ensure multiple readers can access concurrently if no writer is active, but writers get
exclusive access.
4.2.2 Input Handling:
o Capture user input to simulate process arrival: type (Reader/Writer) and ID.
o Allow dynamic arrival of multiple processes.
o Validate the process type and ensure logical constraints are followed.
o Optional: allow user to set the number of processes in advance.
4.2.3 Output Display:
o Display status updates: which process is accessing, waiting, or released.
o Log transitions such as "Reader X granted access", "Writer Y waiting", etc.
o Highlight mutual exclusion and fairness during execution.
o Include visual states (console or simple GUI) for educational understanding.
4.2.4 Modularity and Code Structure:
o Separate modules for:
11
Input simulation
Monitor synchronization logic
Output display/logging
o Use classes/functions for Reader, Writer, and Monitor.
o Keep the logic modular for maintainability and testing.
4.2.5 Error Handling:
o Handle invalid user input (e.g., incorrect process type or missing ID).
o Detect deadlocks or logic errors due to improper synchronization.
o Output clear messages for synchronization rule violations (if any).
4.2.6 Versatility and Scalability:
o Design system to handle varying numbers of readers and writers.
o Ensure the system scales without logical race conditions or starvation.
o Include optional implementation for fairness (e.g., no writer starvation).
4.2.7 Documentation:
o Comment code thoroughly, especially synchronization logic.
o Document key methods (e.g., requestRead, requestWrite, releaseAccess).
o Provide a Readme with instructions on running the simulation and understanding the
monitor behaviour.
4.2.8 Testing and Debugging:
o Develop test scenarios:
Multiple readers
Writer with multiple readers queued
Alternating readers and writers
o Use logs or trace outputs to debug state transitions.
o Ensure all synchronization paths are verified (e.g., signal waking up waiting writers).
12
4.2.9 Educational Features:
o Add console or inline comments to explain what's happening.
o Display monitor states for each request and release.
o Explain access rules as the simulation runs (e.g., “Writer blocked due to active readers”).
13
4.3 MODULES DESCRIPTION
4.3.1 Input Module:
o Captures user input through the console or GUI for simulating processes.
o Users can specify the process type (Reader or Writer), ID, and optional parameters like
arrival time or priority.
o Validates that the input is logical and follows the system’s constraints (e.g., non-duplicate
IDs, proper type names).
o Converts input into structured data suitable for processing in the monitor-based system.
4.3.2 Monitor Synchronization Module:
o Core module handling the logic of the monitor, managing mutual exclusion and
synchronization.
o Implements condition variables and uses wait() and signal() mechanisms to control
access.
o Handles multiple readers simultaneously only when no writer is active, while ensuring
writers get exclusive access.
o Encapsulates the monitor logic in a modular and reusable format for ease of simulation.
4.3.3 Output Module:
o Displays the real-time state of the system, including which processes are reading, writing,
or waiting.
o Presents textual feedback such as:
“Reader R2 is reading.”
“Writer W1 is waiting (readers active).”
o May include simple visualization (table or process queue) to enhance comprehension.
o Ensures clarity during transitions and completion of each operation.
4.3.4 Validation Module:
o Verifies that synchronization is correctly maintained:
14
No two writers are active at the same time.
Writers do not read or write when readers are active (and vice versa).
o Monitors the sequence of signals and waits to ensure fair and deadlock-free execution.
o Flags logical inconsistencies such as starvation, race conditions, or unexpected behavior.
4.3.5 User Interface Module:
o Manages the interaction between the user and the simulation system.
o Provides clear prompts such as:
“Enter number of processes:”
“Specify type (R/W) and ID:”
o Guides users step-by-step, offering a smooth experience across input, processing, and
output stages.
o Can be expanded to include a GUI for easier process visualization in future versions.
4.3.6 Educational Module:
o Offers inline educational content for users to understand how monitors work.
o Displays messages such as:
“Writer W3 is blocked until all readers complete.”
“Reader R1 enters critical section (shared read access).”
o Useful for students learning synchronization and operating systems principles.
o Helps demystify real-time concurrent behavior through traceable simulation.
4.3.7 Error Handling Module:
o Detects and responds to:
Invalid user input (e.g., unrecognized process type).
Synchronization errors (e.g., signal sent without a corresponding wait).
o Provides descriptive error messages to help users understand and correct issues.
o Ensures graceful handling of edge cases, improving robustness of the system.
15
4.3.8 Scalability Module:
o Designed to handle any number of reader and writer processes.
o Ensures the system remains stable as complexity increases (e.g., 20+ simultaneous
processes).
o Allows for extension with new features like:
Reader-writer priority modes.
Real-time simulation with arrival delays.
o Promotes flexibility for classroom demonstrations or advanced OS simulations.
4.3.9 Documentation Module:
o Includes in-code comments for critical logic such as:
Entry/exit sections for readers and writers.
Wait/signal interactions within the monitor.
o Provides a README file outlining:
How to run the simulation.
The rules governing the Readers-Writers problem.
Sample input/output for better understanding.
o Supports maintenance, collaboration, and future upgrades.
4.3.10 Testing and Debugging Module:
o Features structured test cases, e.g.:
readers followed by 1 writer.
Alternating writers and readers with overlaps.
o Logs internal state changes to help trace errors in behavior.
o Provides hooks for breakpoints and output dumps for debugging monitor behavior.
o Ensures correctness, fairness, and reliability of the system under various loads.
16
5. IMPLEMENTATION
The implementation of the Readers and Writers Problem using Monitors is done in Java
using object-oriented principles and thread synchronization mechanisms. Java is chosen due to
its robust thread handling capabilities and built-in monitor concept via synchronized
methods/blocks and object-based locking.
5.1 TECHNOLOGIES USED
5.1.1 Back-end Technology:
Java:
o Java provides built-in monitor-like behavior using synchronized methods and objects.
o Thread classes and synchronization primitives like wait() and notifyAll() are used to
simulate reader and writer interactions safely.
5.1.2 Front-end Technology:
Console Interface:
o The project uses Java’s Scanner class to take input from the user.
o The interface displays real-time reader/writer operations, wait statuses, and critical
section access.
o Although simple, it offers educational insights into concurrency mechanisms.
17
5.2 SAMPLE CODE
import [Link];
class Monitor {
private int readers = 0;
private boolean writerActive = false;
// Reader tries to enter
public synchronized void startRead(int id) throws
InterruptedException {
while (writerActive) {
[Link]("Reader " + id + " is waiting (writer
active).");
wait();
}
readers++;
[Link]("Reader " + id + " starts reading. (Readers
active: " + readers + ")");
}
// Reader exits
public synchronized void endRead(int id) {
readers--;
[Link]("Reader " + id + " finished reading.");
if (readers == 0) {
notifyAll(); // Let waiting writers proceed
}
}
// Writer tries to enter
public synchronized void startWrite(int id) throws
InterruptedException {
while (writerActive || readers > 0) {
[Link]("Writer " + id + " is waiting (readers or
another writer active).");
wait();
}
writerActive = true;
[Link]("Writer " + id + " starts writing.");
}
// Writer exits
public synchronized void endWrite(int id) {
writerActive = false;
[Link]("Writer " + id + " finished writing.");
notifyAll(); // Let waiting readers or writers proceed
}
}
class Reader extends Thread {
private final Monitor monitor;
private final int readerId;
18
public Reader(Monitor monitor, int readerId) {
[Link] = monitor;
[Link] = readerId;
}
public void run() {
try {
[Link](readerId);
[Link](1000); // Simulate reading time
[Link](readerId);
} catch (InterruptedException e) {
[Link]("Reader " + readerId + " interrupted.");
}
}
}
class Writer extends Thread {
private final Monitor monitor;
private final int writerId;
public Writer(Monitor monitor, int writerId) {
[Link] = monitor;
[Link] = writerId;
}
public void run() {
try {
[Link](writerId);
[Link](1500); // Simulate writing time
[Link](writerId);
} catch (InterruptedException e) {
[Link]("Writer " + writerId + " interrupted.");
}
}
}
public class ReadersWritersSimulation {
public static void main(String[] args) {
Scanner scanner = new Scanner([Link]);
Monitor monitor = new Monitor();
[Link]("Enter number of readers: ");
int r = [Link]();
[Link]("Enter number of writers: ");
int w = [Link]();
Thread[] readers = new Thread[r];
Thread[] writers = new Thread[w];
// Launch readers
for (int i = 0; i < r; i++) {
readers[i] = new Reader(monitor, i + 1);
readers[i].start();
}
// Launch writers
19
for (int i = 0; i < w; i++) {
writers[i] = new Writer(monitor, i + 1);
writers[i].start();
}
// Wait for all threads to complete
try {
for (Thread reader : readers) {
[Link]();
}
for (Thread writer : writers) {
[Link]();
}
} catch (InterruptedException e) {
[Link]("Main thread interrupted.");
}
[Link]("Simulation complete.");
}
}
20
6 OUTPUT SCREENS
21
7 CONCLUSION
7.1 CONCLUSION
The Readers and Writers Problem using Monitors project successfully demonstrates the classical
synchronization problem in the realm of concurrent programming. This Java-based
implementation uses built-in monitor methods (synchronized, wait(), notifyAll()) to effectively
manage concurrent access to a shared resource. By simulating reader and writer threads, the
system enforces mutual exclusion and fairness, ensuring data consistency while allowing
maximum concurrency. The use of multithreading in Java, alongside proper synchronization
constructs, highlights the practical applicability of operating system principles in real-world
software systems. The project simulates realistic scenarios where multiple readers and writers
attempt to access a shared resource simultaneously. Readers are allowed concurrent access as
long as no writer is active, while writers are given exclusive access, thus eliminating race
conditions. The modular design enhances the clarity, maintainability, and extensibility of the
project. The clear separation of Monitor, Reader, and Writer classes demonstrates good object-
oriented design principles. Overall, this project serves as a strong learning tool for understanding
synchronization and thread management in Java, with relevance in both academic and industry
environments.
22
7.2 FUTURE ENHANCEMENTS
Future enhancements to the Readers and Writers Problem using Monitors project could involve
incorporating a graphical user interface (GUI) to visualize the thread behavior dynamically. A
real-time display showing when readers or writers access the resource would provide an intuitive
understanding of how monitor-based synchronization works under the hood. The project can also
be expanded by implementing variations of the Readers-Writers problem, such as writer-
preference, reader-preference, and fair solutions that prevent starvation. These variations can be
built using advanced concurrency constructs like ReentrantLocks or Semaphores instead of
relying solely on Java’s synchronized keyword. Another enhancement would be to include
features such as priority-based access, timeouts for thread execution, and live monitoring of
thread states. These additions would make the simulation more aligned with real-world
concurrency control mechanisms. Furthermore, adapting the project for a distributed
environment using networking concepts like Java RMI or sockets would add a new dimension to
the simulation and increase its practical relevance.
23
8 BIBLIOGRAPHY
8.1 WEBSITE REFERNCES
[Link]
[Link]
[Link]
[Link]
[Link]
24
4
