Lecture Notes for Concurrent Programming

24 June 2003 - Using Semaphores


A mutex is most likely to be initialized as locked when it's protecting a shared resource that has to be initialized before it can be used. The intention is to delay the resource-using computations until the resource is ready. The initializing computation can be thought of as holding the resource's lock, which it releases when initialization is complete.

Delaying access until a resource is initialized is not a situation that a critical section can easily handle. Critical sections strictly pair enter() and exit() calls, and the implicit enter() call by the initialization computation can cause trouble (not insurmountable trouble, but the resulting code is more complex than it would be with mutex semaphores).

An alternative approach to synchronizing with resource initialization is to avoid creating the using computations until the resource is initialized. This approach cuts down on concurrency, particularly if resource initialization is lengthy and the using computations have other things they could be doing while waiting for the resource. This approach is also dangerous if the resource is a wide-spread global resource because the resource is being accessed without benefit of mutual exclusion. Later modifications to the code, even if they properly lock the resource's mutex, might access the resource at the same time its being initialized.


This page last modified on 24 June 2003.