Reader/Writer Problem with Writer Preference.

Farida Aliyeva
5 min readNov 4, 2020

In the following code snippet, I tried to improve the default implementation of the reader/writer problem.

Considering the vast amount of reader threads, there is a lower possibility of writer thread to acquire the desired lock ( let’s assume it to be a DB lock). For that purpose, I can give the writer thread a so called preference that whenever a writer has an intention to access the database or any other file, the readers should wait for the writer thread to finish the modification. Therefore, in order to simulate the problem and implement the solution I decided to use a general txt file, even 3 txt files ( the copies of the same file), in order to keep the balance with the minimal difference of the number of reader threads, trying to access each file. That is, whenever a reader thread is trying to access the file, it will be forwarded to one of the 3 copies.

Now, coming up to the implementation details. To simulate this problem, I decided to point out some bulletpoints that i would stick to:

1. Use any of the kernel resources that provide synchronization services: Semaphores, Mutexes, Monitors.

2. Indefinite amount of reader threads spawning at random.

3. Single writer thread which tries to access the file at random periods.

4. 3 txt files (copies).

5. Balance in the number of reader threads accessing files.

6. Writer thread locking and modifying all the copies at once.

https://github.com/Farida004/ReaderWriterProblem — Here you can find the source code to the Java implementation as well as txt files, I created.

As mentioned above, it is required to use any of the synchronization service providers, therefore I used Java Semaphores which served as a Mutex.

Declaring mutex and count varibales.

As you can see from the code snippet above, the access count to each Semaphore is 1 which in turn emphasizes it to be a Mutex.

Reader class.

As you can see in the Reader class we mainly take care about lock acquire and releases. At first, the lock is on the readers after which the read count is incremented to keep track of the exact number of reader threads. Checks if your are the first reader and locks the resource if true. Then we enter a critical section where the read from the files operation is performed. Before the critical section we release the entry section to allow other readers to acquire the lock. As long as the thread read from the file we decrement the read count to indicate that reader is leaving. Afterwards, it checks whether you are the last reader to leave and releases the lock if true. Finally, release the section for the other readers.

Main part of read method.

In the following method I made us of a BufferedReader class to read from the txt files. Additionally, I used a Random class to provide a random access to each of the txt files. And finally as long as the reader reaches the empty line the loop breaks and the contents are printed put to the console.

Writer class.

We start by locking the readers first and then take place for the writer. This is the main point of writer priority — we block the readers whenever writer comes in. After that we enter critical section where we perform the write to the file operation. As you may have noticed we do not check for the first writer entered and the last writer entered, that is because we do not actually need this information as long as we have only one writer in our simulation. Finally, we release the locks.

Main part of write method.

Here I made us of PrintWriter class to actually write contents to the files. In the while loop we check for the stopword which is “THE END” which indicates the end point of the input content.

Now it is time to show the output.

While running the program the first thread that appeared was a writer thread.

Writing to the file.

Right after we can see the numerous reader threads fighting for the access to the file and we can also notice the contents of the files printed in the console. Although, the ordering is messed up because of enormous amount of threads reading the files. From the picture on the right we can observe the number of reader threads working which is 600+ in our case. But it could be even bigger if we didn’t terminate the program at some point (my laptop was just producing sounds similar to Elon Musk’s Falcon 9 take-off).

Output 1.
Output 2.

Finally, as mentioned above one of the requirements was that a writer thread updates all the 3 copies simultaneously. And here is the result. Once we wrote “Hello World, Karabakh is Azerbaijan!!!” to the console it appeared in all 3 copies of the file.

Text files output.

Thank you for your precious time :)

References:

--

--

Farida Aliyeva

Data Scientist at SDH | MS Graduate in Computer Science and Data Analytics