This leads us to Rule 7 for implementing deadlock free accesses to shared resources. When the access to the shared structure does not involve any communication primitives that are blocking, then the use of semaphores can be replaced be the creation of section run in high-priority mode. If, however, communication primitives are an integral part of the access to the shared resource, then semaphores must be employed. We have been using semaphores until now by assuming a superficial knowledge of their inner working. Now is a good time to discuss semaphores and locks in general.
Semaphores are locks.
A lock is usually associated with a resource, such as shared data, and is a mechanism for preventing parallel tasks or processes to access that resource in parallel, and in particular, to interleave their access. Since the parallel accesses to the resource are prohibited, another way of defining the lock is to say that it enforces serialization of access . We say that a lock is safe if the resource it protects can never be left in an indeterminate state. If N parallel tasks access the shared resource protected by a safe lock, then the result of the N accesses must be predictable. We may not be able to know the order in which the tasks are granted access to the resource, nor the intermediate state of the resource during the accesses, but the final state must be predictable.