This “Multiple Reader – Writer” lock is our fourth kind of semaphore.It is becoming available in a number of multi-core oriented embedded operating systems.In particular, it can be found in Symmetric Multi-Processing (“SMP”) operating systems with origins either in the world of traditional single-CPU real-time operating systems (RTOS) or origins in the world of SMP Linux. And we want to prevent reading of the seat map while the seat reservations are in the midst of being updated.Ī “Multiple Reader – Writer” lock can do this with optimal efficiency, by allowing multiple simultaneous readers when there is no active writer, and no simultaneous access at all during active writing. When all of those customers ask about the seat map, we would like to provide them with this information as quickly as possible – all at the same time, rather than one-after-another.īut if one of those customers actually decides to reserve a seat or two, we want to allow only that one customer to select that seat or two.We want to prevent different customers from attempting to reserve the same seat(s) at the same time. Traditional semaphores do not offer this flexibility, as they instead limit access to the data area to only one single reader task when there is no task writing.Thus, traditional semaphores are a less-than-optimal solution for the multiple readers – writer problem.Īn application example is the management of an airline reservation seat map data base.Many different air travel customers may be interested in certain seats on a certain flight, and may ask to see the seat map of nearby seats at the same time.For instance, a customer in San Francisco, and another in Berlin, and another in Tel-Aviv may all at once inquire about the seats near seat 18D in Figure 1 below.įigure 1:Airline reservation seat map example of “Multiple Readers – Writers” problem.