Locks

From the introduction to concurrency, we saw one of the fundamental problems in concurrent programming: we would like to execute a series of instructions atomically, but due to the presence of interrupts on a single processor (or multiple threads executing on multiple processors concur-rently), we couldn’t. In this chapter, we thus attack this problem directly, with the introduction of something referred to as a lock. Programmers annotate source code with locks, putting them around critical sections, and thus ensure that any such critical section executes as if it were a sin-gle atomic instruction. 28.1 Locks: The Basic Idea As an example, assume our critical section looks like this, the canonical update of a shared variable: balance = balance + 1; Of course, other critical sections are possible, such as adding an ele-ment to a linked list or other more complex updates to shared structures, but we’ll just keep to this simple example for now. To use a lock, we add some code around the critical section like this: 1 lock_t mutex; / / some globally-allocated lock ’mutex’ 2... 3 lock(&mutex); 4 balance = balance + 1; 5 unlock(&mutex); A lock is just a variable, and thus to use one, you must declare a lock variable of some kind (such as mutex above). This lock variable (or just “lock ” for short) holds the state of the lock at any instant in time. It is ei-ther available (or unlocked or free) and thus no thread holds the lock, or acquired (or locked or held), and thus exactly one thread holds the lock and presumably is in a critical section. We could store other information 1