- 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() Wait until no writers Access database Check out – wake up a waiting writer Writer() Wait until no active readers or writers Access database 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:-
- 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.
- 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.
- Monitors also have a mechanism for signaling other threads that such conditions have been met.
- So in this implementation only mutual exclusion is not enough. Threads attempting an operation may need to wait until some assertion P holds true.
- 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.
Understanding the solution:-
- It wants to be fair.
- If a writer is waiting, readers queue up.
- If a reader (or another writer) is active or waiting, writers queue up.
- This is mostly fair, although once it lets a reader in, it lets ALL waiting readers in all at once, even if some showed up “after” other waiting writers.
- In the “EndWrite” code (it signals CanWrite without checking for waiting writers)
- In the EndRead code (same thing)
- In StartRead (signals CanRead at the end)
With Semaphores we never did have a “fair” solution of this sort. In fact it can be done but the code is quite tricky. Here the straightforward solution works in the desired way! Monitors are less error-prone and also easier to understand.
- Operating System | Process Synchronization | Set 2
- Operating System | Sleeping Barber problem
- Producer Consumer Problem using Semaphores | Set 1
- Operating System | Dining Philosopher Problem Using Semaphores
- Operating System | Lock variable synchronization mechanism
- Operating System | Page Fault Handling
- Operating System | Dining-Philosophers Solution Using Monitors
- Peterson's Algorithm for Mutual Exclusion | Set 1 (Basic C implementation)
- Readers-Writers Problem | Set 1 (Introduction and Readers Preference Solution)
- Priority Inversion : What the heck !
- Process Synchronization | Monitors
- Deadlock Prevention And Avoidance
- Operating System | Process Management | Deadlock Introduction
- Operating System | Process Management | Introduction
- Mutex vs Semaphore
If you like GeeksforGeeks and would like to contribute, you can also write an article using contribute.geeksforgeeks.org or mail your article to email@example.com. See your article appearing on the GeeksforGeeks main page and help other Geeks.
Please Improve this article if you find anything incorrect by clicking on the "Improve Article" button below.