modern-multithreading-c-java

the operations of each individual processor appear in this sequence in the order specified by its program.”

Note that sequential consistency does not require the actual execution order of operations to be consistent with any particular sequential order. In particular, operations of the same processor may be performed in an order that differs from program order as long as both orders give the same result [Anderson 2001]. We use a similar notion of consistent executions during program replay. The events exercised during replay may be performed in an order that differs from the original execution as long as both executions give the same result. For example, two concurrent write events on different shared variables can be performed in either order.

Sequential consistency may not hold for several reasons [Adve and Gharachorloo 1995]:

žDue to performance optimizations performed by the compiler or the memory hardware, the actual order of execution of the shared variable read and write operations of a thread may be different from the order specified in the program, and the result of the execution may violate the semantics of sequential consistency.

žIf multiple copies of the same shared variable exist, as is the case with cachebased multiprocessor systems and certain compiler optimizations, and if all the copies are not updated at the same time, different threads can individually observe different ReadWrite-sequences during the same execution [Dubois et al. 1988] (see Exercise 2.15).

In such cases, the effects of compiler and hardware optimizations create a larger number of possible interleavings than is implied by the program’s source code. More important, the actual order of read and write operations might not be known at the program level; rather, the order may be known only at the hardware level. The result of all this is that the actual SYN-sequence of an execution may involve low-level events such as cache invalidations and therefore may be unobservable and uncontrollable at levels above the hardware. Verifying program correctness then becomes a “monumental task” [Lamport 1979].

Following is a simple example that illustrates the complexity of dealing with shared memory consistency. Thread1 and Thread2 communicate using shared variables x and y:

int x = 1; boolean y = false;

If Thread2 finds that y is true, Thread2 might also expect x to be 0 since Thread1 assigns 0 to x before it assigns true to y. But there are several reasons why this might not be the case:

1.If each thread is allowed to keep a private copy of shared variable y in a register in order to speed up access to y, the update to y by Thread1 will not be visible to Thread2. Thus, Thread2 will always find that y is false.

2.Hardware optimizations such as allowing write operations to overlap can result in reorderings of the write operations in Thread1. Thus, y may be assigned true before x is assigned 0.

3.A compiler optimization may reorder the assignment statements in Thread1 so that the assignment to y is performed before the assignment to x.

Guaranteeing sequential consistency would rule out these and some other optimizations, which would also mean that these optimizations could not be used to speed up individual sequential processors. Instead of slowing down all the processors, programmers are asked to identify the places in the program at which the optimizations should be turned off.

In Section 2.1.5 we saw that one way to turn off optimizations on shared variables is to declare them as volatile. Declaring a variable as volatile indicates that the value of the variable may be read or written from outside the thread or even outside the program in which the variable appears. For instance, in the example program above, the value of variable y in Thread2 can be changed by Thread1. If y is declared as volatile, the compiler will ensure that updates to y by Thread1 are immediately visible to Thread2. As another example, consider a program that used memory-mapped I/O. A variable’s memory location may be mapped to a data port for an input device. This allows the program to perform input simply by reading the value of the variable. Since the variable is written by the input device, not by the program, the compiler may assume that the value of the variable never changes and then perform optimizations that are based on this incorrect assumption. Declaring the variable as volatile turns these optimizations off for this variable.

In our example Java program we can deal with problem 1 above by declaring y to be volatile:

volatile boolean y = false; int x = 1;

This prohibits the compiler from allocating y to a register. However, in versions of Java before J2SE 5.0, problems 2 and 3 remain even when y is declared as volatile. In these earlier versions, reads and writes of volatile variables cannot be reordered with reads and writes of other volatile variables, but they can be reordered with reads and writes of non-volatile variables. This type of reordering is prohibited in J2SE 5.0. Thus, if Thread2 reads the value true for

y, it is guaranteed to see the write of 0 to x that happened before the write of true to y, even though x is not volatile.

The compiler ensures that the reordering rules for volatile variables are obeyed by emitting special memory barrier instructions, which control the interactions among the caches, memory, and CPUs. The atomic XADD (Exchange and Add) instruction mentioned in Section 2.2.1 is an example of a memory barrier. Prior to executing an XADD instruction, the processor ensures that all previous read and write operations have been completed.

The semantics of volatile variables and other issues related to shared memory consistency in Java are spelled out in the Java Memory Model, which is part of the Java Language Specification. The goal of the Java Memory Model is to ensure that multithreaded Java programs can be implemented correctly on a variety of hardware platforms and with a variety of compiler and hardware optimizations. Programmers can rely on the guarantees provided by the Java Memory Model when they are reasoning about the possible behavior of their programs. The original Java Memory Model had several flaws [Pugh 2000] that were fixed in J2SE 5.0. Since C++ does not have threads built into the language, C++ does not have a memory model like Java’s. The reorderings that are permitted in a multithreaded C++ program depend on the compiler, the thread library being used, and the platform on which the program is run [Meyers and Alexandrescu 2004a,b].

In the next two chapters we study higher-level synchronization constructs that are designed to hide some of the complexity we’ve seen in this chapter. Creating critical sections will be easier with these constructs, as will be execution tracing and replay. As it turns out, critical sections are exactly the place where special care is needed to ensure sequential consistency. Thus, these synchronization constructs are implemented with memory barrier instructions that guarantee sequential consistency as a side effect of using the constructs to create critical sections.

FURTHER READING

Our treatment of the critical section problem in Section 2.1 follows [Silberschatz et al. 1991]. The first solution to the two-process critical section problem was developed in 1962 by Th. J. Dekker [Dijkstra 1968]. Edsger Dijkstra [1965] presented the first solution to the n-process critical section problem. Dijkstra’s solution satisfied mutual exclusion but was not starvation free. Knuth’s [1966] solution remedied this, and further improvement’s in the algorithm’s fairness were presented by deBruijn [1967] and Eisenberg and McGuire [1972]. Lamport [1974] pointed out that all of these solutions assumed atomic reads and writes and presented his bakery algorithm (see Section 2.2.2). Anderson [2001] surveys Lamport’s other contributions to research on mutual exclusion.

Mellor-Crummey and Scott [1991] analyzed the performance of five hardwarebased busy-waiting solutions to the critical section problem for shared-memory

multiprocessors. Adve and Gharachorloo [1995] have written a tutorial on shared memory consistency.

REFERENCES

Adve, Sarita V., and K. Gharachorloo (1995). Shared Memory Consistency Models: A Tutorial. Western Research Laboratory Research Report 95/7. http://www.research. digital.com/wrl/home.html.

Anderson, J. (2001). Lamport on mutual exclusion: 27 years of planting seeds. Proc. 20th Annual ACM Symposium on Principles of Distributed Computing, pp. 3–12.

Andrews, Gregory R. (1991). Concurrent Programming: Principles and Practice. Redwood City, CA: Benjamin-Cummings.

Choi, J., and H. Srinivasan (1998). Deterministic replay of Java multithreaded applications. Proc. ACM Sigmetrics Symposium on Parallel and Distributed Tools, pp. 48–59.

deBruijn, N. G. (1967). Additional comments on a problem in concurrent programming. Communications of the ACM, Vol. 10, No. 3, pp. 137–138.

Dijkstra, Edsger W. (1965). Solution of a problem in concurrent programming control. Communications of the ACM, Vol. 8, No. 9 (September), p. 569.

Dijkstra, Edsger W. (1968). Cooperating sequential processes. In F. Genuys (Ed.), Programming Languages. New York: Academic Press, pp. 43–112.

Dubois, M., C. Scheurich, and F. A. Briggs (1988). Synchronization, coherence, and event ordering in multiprocessors. IEEE Computer, Vol. 21, No. 2, pp. 9–21.

Eisenberg, M. A., and M. R. McGuire (1972). Further comments on Dijkstra’s concurrent programming control problem. Communications of the ACM, Vol. 15, No. 11 (November), p. 999.

Knuth, D. (1966). Additional comments on a problem in concurrent programming. Communications of the ACM, Vol. 9, No. 5 (May), pp. 321–322.

Lamport, L. (1974). A new solution of Dijkstra’s concurrent programming problem. Communications of the ACM, Vol. 17, No. 8 (August), pp. 453–455.

Lamport, L. (1979). How to make a multiprocessor computer that correctly executes multiprocess programs. IEEE Transactions on Computers, Vol. 28, No. 9 (September), pp. 690–691.

LeBlanc, T. J., and J. M. Mellor-Crummey (1987). Debugging parallel programs with Instant Replay. IEEE Transactions on Computers, Vol. 36, No. 4 (April), pp. 471–482.

Mellor-Crummey, John M., and Michael L. Scott (1991). Algorithms for scalable synchronization on shared-memory multiprocessors. ACM Transactions on Computer Systems, Vol. 9, No. 1 (February), pp. 21–65.

Meyers, Scott, and Andrei Alexandrescu (2004a), C++ and the perils of double-checked locking: Part I. Dr. Dobb’s Journal, August, pp. 46–49.

Meyers, Scott, and Andrei Alexandrescu (2004b), C++ and the perils of double-checked locking: Part II. Dr. Dobb’s Journal, September, pp. 57–61.

Pugh, William (2000). The Java memory model is fatally flawed. Concurrency: Practice and Experience, Vol. 12, No. 1 (January), pp. 1–11.

Silberschatz, A., J. L. Peterson, and P. Galvin (1991). Operating Systems Concepts. Reading, MA: Addison-Wesley.

EXERCISES

2.1.The following solutions are intended to solve the two-thread critical section problem. Thread0 and Thread1 execute the same code, which is shown below. When Thread0 executes the code, i is 0 and j is 1. When Thread1 executes the code, i is 1 and j is 0. Variable turn can be initialized to 0 or 1. The execution of the break statement inside the first while-loop transfers control to the statement immediately following the loop. For each solution, determine whether it guarantees mutual exclusion. If mutual exclusion is guaranteed, determine whether it guarantees progress. If mutual exclusion and progress are guaranteed, determine whether it guarantees bounded waiting. Justify your answers.

2.2.In Peterson’s algorithm, is every assignment statement atomic? Explain.

2.3.The “eventual entry” requirement for the critical section problem is as follows: A thread that intends to enter its critical section must eventually succeed.

(a)If the progress requirement is satisfied, does that necessarily imply that eventual entry is also satisfied? Explain.

(b)If the bounded waiting requirement is satisfied, does that necessarily imply that eventual entry is also satisfied? Explain.

(c)If the eventual entry requirement is satisfied, does that necessarily imply that progress and bounded waiting are also satisfied? Explain.

2.4.For Peterson’s algorithm, is it necessary to assume that Thread0 and Thread1 have the same priority? Explain.

2.5.Suppose that we switch the order of the first two statements in Peterson’s algorithm:

boolean intendToEnter0 = false, intendToEnter1 = false; int turn; // no initial value for turn is needed.

Does the modified solution guarantee mutual exclusion? Explain. If yes, does the modified solution guarantee progress and bounded waiting? Explain.

2.6.For the bakery algorithm in Section 2.2.2, assume that thread Ti, i > 0, has just executed statement (3) and thread Tk, k != i, is in its critical section. Prove that (number[i],i) > (number[k],k).

2.7.For the bakery algorithm in Section 2.2.2, the value of number[i] is not bounded.

(a)Explain how the value of number[i] grows without bound.

(b)One suggestion for bounding the value of number[i] is to replace the statement

number[i] = max(number) + 1;

with the statement

// numThreads is # of threads in the program number[i] = (max(number) + 1) % numThreads;

Is this suggestion correct? Explain.

2.8.Simplify the bakery algorithm in Section 2.2.2 for the case where there are only two threads, Thread0 and Thread1. Use turn0 and turn1 to denote number[0] and number[1] , respectively. Try to simplify the algorithm as much as possible.

2.9.Suppose that a computer has an atomic DecrementAndCompare() function:

int DecrementAndCompare (int& v) { // done atomically v = v - 1;

if (v>=0) return 0; else return 1;

}

(a)Is the following a correct solution to the n-thread critical section problem?

(b)How can DecrementAndCompare() be used to develop a critical section solution for n threads? Your solution does not have to satisfy the bounded waiting requirement.

2.10.Assume that each thread in Peterson’s algorithm runs on a separate processor. Also assume that processors use a write buffer with bypassing capability. On a write, a processor inserts the write operation into a write buffer and proceeds without waiting for the write to complete. Subsequent reads are allowed to bypass any previous writes in the write buffer for faster completion. This bypassing is allowed as long as the read address

does not match the address of any of the buffered writes (on the same processor). Can Peterson’s algorithm fail if write buffers are used?

2.11.The java.concurrent.atomic package introduced in J2SE 5.0 provides class AtomicBoolean to store Boolean values. Method set(b) sets the stored value to b, while getAndSet(b) atomically replaces the stored value with value b and returns the previous value. Thus, getAndSet() is equivalent to the testAndSet instruction provided by some machines.

(a)Show how to use getAndSet() to solve the critical section problem by writing a solution that is similar to the partial solution in Section 2.3.1.

(b)Use getAndSet() to solve the critical section problem by writing a solution that is similar to the second solution in Section 2.3.3 (i.e., the one that use two loops).

(c)Fine-tune your solution to part (b) by using the exponential backoff technique. If a thread’s call to getAndSet() fails to acquire the lock, the thread should sleep for some random amount of time between 0 and 32 milliseconds. If the next call to getAndSet() also fails, double the maximum sleep time (i.e., the thread should sleep a random amount of time between 0 and 64 milliseconds). Continue doubling the maximum sleep time until it reaches some upper bound, then stop doubling the maximum sleep time if further calls fail. The idea behind this scheme is as follows. If a call to getAndSet() fails, threads are contending for the critical section. The contending threads should sleep a random amount of time (i.e., “back off”) so that they all don’t try to acquire the lock again at the same time. The more times getAndSet() fails, the more contention there is and the greater variability there should be in the amount of time threads should sleep before they try again.

2.12.Consider a program such as the following, which is similar to Listing 1.9:

Modify this program so that Thread0 and Thread1 take turns incrementing s, starting with Thread0. Use one of the solutions to the critical section problem to create critical sections for Thread0 and Thread1. Then use an integer to keep track of whose turn it is to do the increment. If a thread tries to increment s out of turn, it should busy-wait in a loop until its turn arrives.

2.13.Consider the following programs, which are executed concurrently on three processors:

int a, b, c, = 0;

Function output() atomically reads and displays the values of the variables passed as arguments. For example, if the statements are executed in the order (1), (2), (3), (4), (5), (6), the program displays 001011.

(a)Assume that the processors execute the statements in program order [i.e., (1) before (2), (3) before (4), and (5) before (6)]. How many possible interleavings of the statements are there?

(b)If processors are allowed to execute the statements out of program order, how many possible interleavings are there?

(c)Is there any interleaving that preserves program order and that produces the output 111111? If so, show an interleaving. You can assume that only a single copy of shared variables a, b, and c, exists (i.e., that shared variables are not cached).

(d)Is there any interleaving, either preserving program order or not preserving program order, that produces the output 011001? If so, show an interleaving. You can assume that only a single copy of shared variables a, b, and c, exists (i.e., that shared variables are not cached).

(e)Repeat part (d), but this time assume that multiple copies of shared variables a, b, and c can exist (as in a cache-based system) and that the copies may not be updated at the same time. This allows different processors to observe different interleavings during the same execution.