Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
588 Shared-State Concurrency Simple lock (gating mechanism) (can be aborted) (ACID properties) ... ... Reentrant lock Monitor Light transaction Full transaction Figure 8.4: The hierarchy of atomic actions 8.2.3 Programming with atomic actions Starting with the next section, we give the programming techniques for shared- state concurrency using atomic actions. We introduce the concepts gradually, starting with locks. We refine locks into monitors and transactions. Figure 8.4 shows the hierarchical relationships between these three concepts. Locks allow to group little atomic operations together into big atomic oper- ations. With a reentrant lock, the same lock can guard discontiguous parts of the program. A thread that is inside one part can reenter the lock at any part without suspending. Monitors refine locks with wait points. A wait point isapa irofanex itand a corresponding entry with no code in between. (Wait points are sometimes called delay points [6].) Threads can park themselves at a wait point, just outside the lock. Exiting threads can wake up parked threads. Transactions refine locks to have two possible exits: a normal one (called commit ) and an exceptional one (called abort ). The exceptional exit can be taken at any time during the transaction. When it is taken, the transaction leaves the execution state unchanged, i.e., as it was upon entry. Figure 8.5 summarizes the principal differences between the three concepts. There are many variations of these concepts that are designed to solve specific problems. This section only gives a brief introduction to the basic ideas. Reasoning with atomic actions Consider a program that uses atomic actions throughout. Proving that the pro- gram is correct consists of two parts: proving that each atomic action is correct (when considered by itself) and proving that the program uses them correctly. The first step is to show that each atomic action, e.g., lock, monitor, or transac- tion, is correct. Each atomic action defines an ADT. The ADT should have an Copyright c ± 2001-3 by P. Van Roy and S. Haridi. All rights reserved.
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
8.2 Programming with concurrency 589 Loc kT r ansaction enter exit commit abort Monitor wait wait Figure 8.5: Differences between atomic actions invariant assertion, i.e., an assertion that is true when there is no thread inside the ADT. This is similar to reasoning with stateful programs and active objects, except that the ADT can be accessed concurrently. Because only one thread can be inside the atomic action at a time, we can still use mathematical induction to show that the assertion is an invariant. We have to prove two things: When the ADT is first defined, the assertion is satisfied. Whenever a thread exits from the ADT, the assertion is satisfied.
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

This document was uploaded on 08/10/2011.

Page1 / 30


This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online