Operating system:three Easy Pieces---Locks (Note)

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 (multiple threads executing on multiple processors concurrently),

We could ' 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 sections executes as if it were a single atomic instruction.

Locks:the Basic Idea

As an example, assume our critical sections looks like this, the canonical update of a shared variable:

Balance = balance + 1;

Of course, other critical sections is possible, such as adding an element to a linked list or other more

Complex updates to GKFX structures, but we'll just keep to this example for now. To use a lock, we

Add some code around the critical section like this:

lock_t Mutex;

.....

Lock (&mutex);

Balance = balance + 1;

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 the lock at any instant in time. It is

Either 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

In the data type as well, such as which thread holds the lock, or a queue for ordering lock acquisition, but

Information like that's hidden from the user of lock.

The semantics of the Lock () and unlock () routines is simple. Calling the routine lock () tries to acquire the lock;

If no other thread holds the lock (i.e. it was free), the thread would acquire the lock and enter the critical section; This

Thread is sometimes said to being the owner of the lock. If Another thread then calls Lock () in that same lock variable

(Mutex in this example), it won't return while the lock was held by another thread; In this, and other threads is

Prevented from entering the critical sections while the first thread that holds the lock are in there.

Once the owner of the The lock calls unlock (), the lock is now-available (free) again. If no other threads is waiting for

The lock (i.e. no other thread had called lock () and is stuck therein), the state of the lock was simply changed to free.

If There is waiting threads (stuck in Lock ()), one of the them would (eventually) notice (or be informed of) the This change

Of the lock ' s state, acquire the lock, and enter the critical section.

Locks provide some minimal amount of control over scheduling to programmers. In general, we view threads as

Entities created by the programmer and scheduled by the OS fashion. Locks yield some

Of that control back to the programmer; By putting a-lock around a section of code, the programmer can guarantee

The no more than a single thread can ever is active within that code. Thus locks help transform the chaos

Traditional OS scheduling to a more controlled activity.

Operating system:three Easy Pieces---Locks (Note)