Hardware Basics

Abstract

A novice was trying to fix a broken Lisp machine by turning the power off and on. Knight, seeing what the student was doing spoke sternly: "You cannot fix a machine just by power-cycling it with no understanding of what is going wrong." Knight turned the machine off and on. The machine worked. (From "AI Koans," a collection of jokes popular at MIT in the 1980s.) B.1 Introduction (and a puzzle) You can do a pretty good job of programming a uniprocessor without understanding much about computer architecture, but the same is not true of multiprocessors. You cannot program a multiprocessor effectively unless you know what a multiprocessor is. We illustrate this point by a puzzle. We consider two programs that are logically equivalent, but one is much less efficient than the other. Ominously, the simpler program is the inefficient one. This discrepancy cannot be explained, nor the danger avoided, without a basic understanding of modern multiprocessor architectures. Here is the background to the puzzle. Suppose two threads share a resource that can be used by only one thread at a time. To prevent concurrent use, each thread must lock the resource before using it, and unlock it afterward. We study many ways to implement locks in Chapter 7. For the puzzle, we consider two simple implementations in which the lock is a single Boolean field. If the field is false, the lock is free, and otherwise it is in use. We manipulate the lock with the getAndSet(v) method, which atomically swaps its argument v with the field value. To acquire the lock, a thread calls getAndSet(true). If the call returns false, then the lock was free, and the caller succeeded in locking the object. Otherwise, the object was already locked, and the thread must try again later. A thread releases a lock simply by storing false into the Boolean field. In Fig. B.1, the test-and-set (TASLock) lock repeatedly calls getAndSet(true) (line 4) until it returns false. By contrast, in Fig. B.2, the test-and-test-and-set lock (TTASLock) repeatedly reads the lock field (by calling state.get() at line 5) until it returns false, and only then calls getAndSet() (line 6). It is important to understand that reading the lock value is atomic, and applying getAndSet() to the lock value is atomic, but the combination is not atomic: Between the time a thread reads the lock value and the time it calls getAndSet(), the lock value may have changed. 519