modern-multithreading-c-java

REFERENCES

Andrews, Gregory R. (2000). Foundations of Multithreaded, Parallel, and Distributed Programming. Reading, MA: Addison-Wesley.

Baldoni, R., and M. Raynal (2002). Fundamentals of distributed computing: a practical tour of vector clock systems. IEEE Distributed Systems Online, http://dsonline. computer.org.

Bartlet, K. A., R. A. Scantlebury, and P. T. Wilkinson (1969). A note on reliable fullduplex transmission over half duplex lines. Communications of the ACM, Vol. 12, No. 5 (May), pp. 260–261.

Bechini, Alessio, and K. C. Tai (1998). Timestamps for programs using messages and shared variables. Proc. International Conference on Distributed Computing Systems, pp. 266–273.

Brzezinski, Jerszy, Jean-Michel, Helary, and Michel Raynal (1993). Distributed termination detection: general models and algorithms. Proc. 13th IEEE International Conference on Distributed Computing Systems.

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

Fidge, C. (1991). Logical time in distributed computing systems. IEEE Computer, Vol. 24, August, pp. 8–33.

Fidge, C. (1996). Fundamentals of distributed system observation. IEEE Software, Vol. 13, No. 6 (November), pp. 77–83.

Garg, Vijay K. (2002). Elements of Distributed Computing. Hoboken, NJ: Wiley.

Gleason, Mike (2001). The ephemeral port range. http://www.ncftpd.com/ncftpd/doc/ misc/ephemeral ports.html#Windows

Hartley, Steven J. (1998). Concurrent Programming: The Java Programming Language. New York: Oxford University Press.

Konuru, R., H. Srinivasan, and J. -D. Choi (2000). Deterministic replay of distributed Java applications. Proc. 14th International Parallel and Distributed Processing Symposium (IPDPS’00), pp. 219–228.

Lamport, L. (1978). Time, clocks, and the ordering of events in a distributed system. Communications of the ACM, Vol. 21, No. 7 (July), pp. 558–565.

Mattern, F. (1989). Virtual time and global states of distributed systems. In M. Cosnard et al. (Eds.), Proc. International Workshop on Parallel and Distributed Algorithms. Amsterdam: Elsevier North-Holland, pp. 215–226.

Netzer, R. B., and B. P. Miller (1993). Optimal tracing and replay for debugging sharedmemory parallel programs. Proc. 3rd ACM/ONR Workshop on Parallel and Distributed Debugging, pp. 1–11.

Pee, James (2001). Guidelines for wrapping sockets in classes. C/C++ Users Journal, December, pp. 10–16.

Plouzeau, N., and M. Raynal (1992). Elements for a course on the design of distributed algorithms. SIGCSE Bulletin, Vol. 24, No. 2, pp. 35–40.

Raynal, M. (1988). Distributed Algorithms and Protocols. New York: Wiley.

Ricart, G., and A. K. Agrawala (1981). An optimal algorithm for mutual exclusion in computer networks. Communications of the ACM, Vol. 24, No. 1 (January), pp. 9–17.

Schmidt, Douglas C., and Stephen D. Huston (2002). C++ Network Programming: Mastering Complexity Using ACE and Patterns. Reading, MA: Addison-Wesley.

Schwarz, R., and F. Mattern (1994). Detecting causal relationships in distributed computations: in search of the Holy Grail. Distributed Computing, Vol. 7, No. 3, pp. 149–174.

Smerka, Richard (2001). Two classes for simple socket programming. C/C++ Users Journal, May, pp. 34–41.

Sobczak, Maciej (2001). An IOStream compatible socket wrapper. C/C++ Users Journal, December, pp. 18–27.

EXERCISES

6.1.For a given execution, let ei be an event in thread Ti and ej be an event in a different thread Tj, i ! = j. If only asynchronous communication is used, then ei εj if and only if VT(ei)[i] ≤ VT(ej)[i]. Give a rule that can be used to determine when events ei and ej are concurrent.

6.2.Show that if event e1 occurs before event e2 in real time, it is possible that the integer timestamp for e1 is greater than the integer timestamp for e2 [i.e., IT(e1)>IT(e2)]. (The real-time order of events e1 and e2 may not be possible to know, but assume that e1 occurs before e2 in real time.) Now consider vector timestamps. If VT(e1) > VT(e2), is it possible that e1 occurred before e2 in real time?

6.3.Figure 6.28 shows a computation of processes P, Q, and R using asynchronous communication. The messages in this computation are p1 → q1, r1 → q2, q3 → p2, p3 → q4, and r2 → q5.

Figure 6.28 A distributed computation.

(a)Determine the integer timestamp of each event in the computation above.

(b)Determine the vector timestamp of each event in the computation above. Each vector timestamp has three elements, with the first, second, and third elements indicating logical clock values for P, Q, and R, respectively.

(c)Indicate all of the events that are concurrent with P3.

(d)Indicate all of the events that are concurrent with R2.

6.4.The Alternating Bit Protocol (ABP) in Section 6.4.3 handles lost messages but assumes that messages are not corrupted, duplicated, or reordered.

Show that reordered messages are not handled correctly by ABP. Messages are considered to be reordered when the order in which they are received is not the same as the order in which they were sent.

6.5.The following is a description of a token-based distributed mutual exclusion algorithm.

There is a single token shared by n threads. A thread cannot enter its critical section unless it holds the token. A thread holding the token may send it to any other thread:

žThe token has a vector [E1, E2, . . . , En], where Ei indicates the number of times thread Ti has entered its critical section.

žWhen thread Ti wants to enter its critical section for the (Mi)th time, it sends the message “request(Ti,Mi)” to all the other threads in the system.

It then waits until it receives the token. At that time, it modifies the token vector by setting Ei = Mi and enters its critical section.

žAfter exiting the critical section, Ti examines the incoming request queue:

žIf the request queue is empty, Ti continues execution (i.e., Ti continues entering and exiting its critical section) until it receives a request message.

žIf the request queue is nonempty, Ti does the following:

do {

If the comparison (Mj > Ej) is replaced with (Mj == Ej+1), is the resulting algorithm correct?

(c)Based on this algorithm, a thread deletes old messages in its request queue only when the thread has the token. But is it possible for a thread to delete old messages when the thread does not have the token? If you believe that it is possible, show how to delete as many old messages as

possible when a thread does not have the token. Your solution cannot involve a thread making a copy of the token before sending it to another thread.

6.6.Suppose that there are two communicating processes. Process P1 sends three messages to process P2, which receives all three messages. The sends are nonblocking, and the order in which messages are received is not necessarily the order in which they are sent. Figure 6.29 shows an incomplete space-time diagram (i.e., the arrows are missing) that describes such a scenario. Assume that each si and rj event is timestamped with a vector timestamp. Is it possible to use the timestamps to complete the space-time diagram by drawing arrows between matching send and receive events? For example, if we determine from the timestamps that the message sent

by s1 must have been received by receive event r5, we would draw an arrow between s1 and r5: s1 → r5. Describe how to use the timestamps to draw the arrows, or show that this cannot be done (i.e., that we cannot always be certain how to draw the arrows based on the information in the timestamps alone).

Figure 6.29 Distributed computation.

6.7.Show how to convert vector timestamps into integer timestamps. The integer timestamps that you generate do not have to have the values that would be produced by the algorithm in Section 6.3.5. Just make sure that if event s happens before event t, the integer timestamp of s is less than the integer timestamp of t.

6.8.Distributed parking lot [Plouzeau and Raynal 1992]. Implement a distributed algorithm for the case where two gate threads (Gate1 and Gate2) control access to a parking lot (Fig. 6.30). The gate threads must communicate by using message passing; no shared variable communication is allowed between the gates. The automobile threads (Auto) call the gates to enter and exit the parking lot. The size of the parking lot is 3. Denote the number of automobiles that have entered the parking lots as “in,” and

the number of automobiles that have exited the parking lot as “out.” Then the following global condition must always be true: in − out ≤ 3.

Figure 6.30 Distributed parking lot.

The Gate threads exchange messages about the count of automobiles that have entered and exited through them. These messages are never lost and they arrive in the order sent. The counters used by the Gates are:

žin1 = number of automobiles that have entered through Gate1

žin2 = number of automobiles that have entered through Gate2

žout1 = number of automobiles that have exited through Gate1

žout2 = number of automobiles that have exited through Gate2

Then the global condition above becomes in1 + in2 − (out1 + out2) ≤ 3. Note that each gate has exact knowledge only about the value of its own counters (e.g., Gate1 knows in1 and out1 but not Gate2’s counters). Thus, neither Gate can evaluate the global condition exactly. Each Gate can, however, maintain a “safe” approximation for the other Gate’s values. (For example, if the value that Gate1 uses for in2 is always greater than or equal to Gate2’s actual value of in2, Gate1 is safe from making errors.) Use a simple request/reply protocol to make sure that each Gate maintains a safe value for the other’s variables. (That is, the Gates will need to exchange messages to coordinate their counters and to make sure that their messages have been seen by the other Gate.)

Make sure you consider the case where the Gates have both sent a request message. Is a deadlock possible in your program? Should one Gate cancel its request? What if the both Gates cancel their requests? How can a tie be broken? For this exercise, you may want to use the channel classes from Chapter 5 instead of the TCP mailbox classes.

6.9.Implement classes TCPEntryClient and TCPEntryServer. Together, they should provide the same interface as class Entry in Chapter 5, and support client–server communication through methods call(), accept(), and reply().

Class TCPEntryClient encapsulates a socket and the stream-based code for communicating with the server. A client creates a TCPEntryClient object and uses it to send a serialized request object to the server and receive a serialized reply object from the server:

TCPEntryClient requestAndReply = new TCPEntryClient(serverHost,serverPort);

...

Message reply = (Message) requestAndReply.call(request);

No connection is made with the server until a call() occurs. Class TCPEntryServer encapsulates a ServerSocket and the stream-based code for communicating with clients. A server creates a TCPEntryServer object and executes accept() to receive a message and reply() to send a reply:

TCPEntryServer requestAndReply = new TCPEntryServer(serverPort); request = (Message) requestAndReply.accept(); requestAndReply.reply(result);

6.10.For diagram D5 in Fig. 6.13, determine the causal relation between the

following pairs of events: (n, o), (b, r), (p, z), (a, z), (a, n), (b, n), (c, n), b, z), (n, w). For a given pair (e1, e2), indicate either e1 e2, e2 e1, or e1 || e2. Justify your answers using rules (HB1)–(HB3) in Section 6.3.5.

6.11.Distributed mutual exclusion. The following questions refer to Listing 6.16:

(a)Suppose that method resetRequesting() is not in the Coordinator monitor (i.e., remove the calls to enterMonitor() and exitMonitor from this method). Suppose further that method deferrMessage() returns the

boolean value deferMessage immediately before the if-statement, so that the statement “deferred[m.ID] = true;” is executed by the helper thread whenever it receives a true return value from deferMessage(). Show that a deadlock is possible.

(b)Suppose that process m decides to enter its critical section and sends a request message to process n. Process n sends a reply to process m indicating that process n does not want to enter its critical section. Suppose further that process n later decides to enter its critical section and sends a request message to process m (and to all the other processes). What happens if process n’s request message is received by process m before process n’s earlier reply message is received by process m?

In earlier chapters we saw several special ways in which concurrent programs can fail, including deadlock, livelock, starvation, and data races. Failures can be caused by hardware or software faults.

žA software fault (or “bug”) is a defective, missing, or extra instruction, or a set of related instructions that is the cause of one or more actual or potential failures.

Faults are the result of human errors. For example, an error in writing an ifelse statement may result in a fault that causes an execution to take a wrong branch. If this execution produces the wrong result, it is said to fail; otherwise, the result is coincidentally correct, and the internal state and path of the execution must be examined to detect the error.

If a test input causes a program to fail, the program is executed again, with the same input, in order to collect debugging information.

ž Debugging is the process of locating and correcting faults.

Since it is not possible to anticipate the information that will be needed to pinpoint the location of a fault, debugging information is collected and refined over the course of many executions until the problem is understood.

After the fault has been located and corrected, the program is executed again with each of the previously tested inputs to verify that the fault has been corrected and that in doing so, no new faults have been introduced. Such testing, called regression testing, is also needed after the program has been modified during the maintenance phase.

This cyclical process of testing, followed by debugging, followed by more testing, is commonly applied to sequential programs. Together, testing and debugging account for at least half of the cost of developing large software systems [Beizer 1979]. Unfortunately, this cyclical process breaks down when it is applied to concurrent programs.

Let CP be a concurrent program. Multiple executions of CP with the same input may produce different results. This nondeterministic execution behavior creates the following problems during the testing and debugging cycle of CP.

Problem 1 When testing CP with input X, a single execution is insufficient to determine the correctness of CP with X. Even if CP with input X has been executed successfully many times, it is possible that a future execution of CP with X will fail.

Problem 2 When debugging a failed execution of CP with input X, there is no guarantee that this execution will be repeated by executing CP with X.

Problem 3 After CP has been modified to correct a fault detected during a failed execution of CP with input X, one or more successful executions of CP with X during regression testing does not imply that the detected fault has been corrected.

Our general framework for understanding and solving these three problems focuses on the synchronization behavior of CP. We assume that CP consists of two or more concurrent processes or threads that communicate and synchronize with each other via constructs such as semaphores, monitors, shared variables, and message passing. An execution of CP is characterized by CP’s inputs and the sequence of synchronization events that CP exercises, referred to as the synchronization sequence (or SYN-sequence) of the execution. The definition of a SYN-sequence is based on the programming language and the synchronization constructs used in the program. We intentionally avoid dealing with implementation-level concerns, such as the compiler, the virtual machine, or the operating system, to keep our framework as abstract and as portable as possible. Defining various types of SYN-sequences is the focus of Section 7.1. In later sections, the general issues and problems that are encountered during testing and debugging are discussed in terms of SYN-sequences. SYN-sequences are used in Section 7.2 to define the paths of a concurrent program and in Section 7.3 to define program correctness and the types of faults in concurrent programs. Section 7.4 describes several approaches to testing concurrent programs. One of these approaches, reachability testing, is described in detail in Section 7.5. All of these approaches were illustrated in earlier chapters.

7.1 SYNCHRONIZATION SEQUENCES OF CONCURRENT PROGRAMS

The definition of a SYN-sequence can be language-based or implementationbased, or a combination of both. A language-based definition is based on the concurrent programming constructs available in a given programming language. An implementation-based definition is based on the implementation of these constructs, including the interface with the run-time system, virtual machine, and operating system. In this section we discuss language-based definitions of SYNsequences. In the following discussion, it is assumed that a concurrent program has no real-time constraints and that all nonsynchronization constructs are deterministic.

Threads in a concurrent program synchronize by performing synchronization operations on synchronization objects, or SYN-objects. For example, threads may perform P() and V() operations on semaphore objects, or send() and receive() operations on channel objects. A synchronization event, or SYN-event, refers to the execution of one of these operations. Thus, an execution of a concurrent program consists of concurrent threads performing SYN-events on SYN-objects. The order in which SYN-events are executed is nondeterministic.

7.1.1 Complete Events vs. Simple Events

Consider the program in Listing 7.1, which uses the synchronous mailboxes defined in Chapter 5. The order in which the messages sent by Thread1 and Thread4 will arrive at mailboxes C1 and C2 is unpredictable. Also, the order in