An Operating Systems Vade Mecum

270 Concurrency Chapter 8share the same semaphore.SemaphoreDestroy(semaphore descriptor). This call informs the kernel thatthe given semaphore is no longer needed. This call is implicitly performed whenthe last process using a semaphore terminates. Any process waiting on a SemaphoreDowncall receives an error return from that call.SemaphoreDown(semaphore descriptor). This call performs the Down operationon the given semaphore. An error is reported if the semaphore is not associatedwith this process or if the semaphore is destroyed while the process is blockedwaiting for it.SemaphoreUp(semaphore descriptor). This call performs the Up operation onthe given semaphore. An error is reported if the semaphore is not associated withthis process.Semaphores have the following properties:They correctly implement a liberal policy of mutual exclusion among any numberof activities on any number of processors. Activities interfere with each other onlyif they refer to the same semaphore.When an activity is blocked from entering its region, it does not busy wait.Starvation is possible unless waiters are unblocked in first-come, first-served order.As with all the methods we have seen so far, there is no guarantee that activitieswill call Down and Up at the correct times. The wrong (or no) call may be made,or the wrong semaphore may be invoked.A semaphore used for mutual exclusion is a serially reusable, non-preemptableresource. Its use is therefore subject to deadlock. A hierarchical order for acquiringmultiple semaphores can be used to prevent deadlock.It is easy to generalize the semaphore to allow any fixed number of activities the right toenter their region at the same time. For example, we might have seven tape drives and bewilling to allow up to seven activities to access tape-drive code. To enforce this policy,we would build a semaphore for tape-drive code and initialize its value to 7 instead of 1.Semaphores allow us to implement synchronization without busy waiting. Forexample, we could introduce a semaphore for each arrow in the synchronization graph ofFigure 8.1: AB, BE, and so on. Each semaphore would be initialized to 0. A typicalactivity, like E, would have this sort of code:1 activity E:2 Down(BE);3 Down(DE);4 perform E’s work;5 Up(EF);6 Up(EH);We don’t really need so many semaphores. Instead, we could introduce just one semaphoreper activity. Again, it would be initialized to 0. When the activity finishes, itinvokes Up on the semaphore as many times as there are activities waiting for this one tofinish. Before an activity starts, it invokes Down on the semaphores of all the activities itneeds to wait for. For example, E looks like this: