An Operating Systems Vade Mecum

chapter 8CONCURRENCYAs operating systems were first built, an annoying sort of problem was discovered: Routinesinvoked from interrupts sometimes modify data that are in the midst of beinginspected by the interrupted program. The modifications can be benign, like appendingto the end of a list, or disastrous, like modifying a linked list in such a way that the interruptedprogram follows a dangling pointer.Such problems crop up in various contexts within operating systems. In Chapter 5,we saw that a circular buffer pool can be simultaneously filled by a process and emptiedby the kernel. It would be erroneous for the process to put new data in the buffer that iscurrently being emptied. In Chapter 6, we encountered read/write and write/writeconflicts in file use. We invented transactions to provide synchronization atomicity toprevent such conflicts. If we allow several processes to share parts of their virtual store,similar conflicts arise. As we suggested in Figure 3.23, the kernel of the operating systemmay be composed of separate tasks, each of which fulfills one particular function.These tasks may communicate through shared data.All these cases involve several activities sharing a common data area. What happenscan depend on the order in which the activities access the data. Some orders givefine results; some give incorrect but not fatal results; others are disastrous. For example,in a video game, it is fine if we move the hero before the monster. It is incorrect todecide where each will go before moving the other, because they could end up in thesame location on the screen. It is disastrous if such overlap leads to dangling pointersthat cause the game to fail. When two cooks are working on the same soup, it is fine ifone chops onions while the other measures barley. It may even be acceptable for them toadd these ingredients at the same time. But if both independently decide to add salt, theresult can be inedible. In this chapter we will present methods for ensuring that differentactivities sharing access to common data give predictable results. This general topic isknown as concurrency control. We use the term activity to avoid specifying whetherour entities are processes, kernel tasks, interrupt-driven procedures, or DMA transfers.From one point of view, shared data can be considered a resource that the operatingsystem must manage to ensure correct use. The problem is therefore in the domain of256