The Readers-Writers Problem
The readers-writers problem is an extension of the critical section problem where two types of processes, readers and writers. However, it involves an interesting issue when the processes compete for access to a common resource. Multiple readers are allowed to enter the critical section concurrently but only one writer is allowed to enter at a time.
The main challenge is to guarantee maximum concurrency of readers while preventing the starvation of either type of process. There are two main rules to this situation.
- A reader is permitted to join other readers currently in the CS only when no writer is waiting. When the last readers exits the CS, the writer is allowed to enter.
- All readers that have arrived while a writer is in the CS must be allowed to enter before the next writer.
A solution to this problem is to use a monitor with two sets of two functions. The ability to start and end both the read and write cycle. read_start(), read_end(), write_start(), and write_end().
Example: An example of this might be where you are updating data on a webpage, but have multiple people trying to access the page due to the nature of it… think of a feed/stream system. Only one process is writing to the feed, but there are multiple threads/processes trying to read that resource as it is being updated.
The Dining-Philosophers Problem
This problem is an example of situations where multiple processes compete for shared resources and each process needs more than one resource at a time. Their need of multiple resources can block other processes.
For example, your software might need access to the camera and microphone. Or you might have a software that needs both your keyboard and mouse, or a hard drive and network card, etc.
Since you need two resources, you must request them at the same time, lest another process lock one of your resources and prevent you from accessing it.
The Elevator Algorithm
A hard drive consists of n concentric tracks that need to be accessed by read/write requests arriving in some unspecified order. The goal is to minimize the travel distance between tracks while preventing starvation.
The elevator algorithm mimics the behavior of an elevator in an n-story building. The elevator (representing the read-write head of the disk), maintains a direction of motion, up or down, for as long as requests for floors (representing disk tracks) exist, in the current direction.
When moving up and no more requests for higher floors exist, the elevator reverses direction and services all requests in descending order. When the request for the lowest floor is serviced, the elevator again reverses direction and proceeds moving up.
The idea is to keep the elevator, or disk head in this case, moving in the same direction to prevent moving back and forth too much.
Various technologies make this particular set less meaningful, including on disk caching and the rise of SSD (solid state drives) which don’t have a moving pieces.
Classic Synchronization Problems was originally found on Access 2 Learn
