modern-multithreading-c-java

5.2.In Exercise 3.11 you were asked to write a semaphore implementation of operation waitB() in class Barrier. Here you are asked to write an implementation using send() and receive() operations and a selective wait statement. Threads call B.waitB() to wait at Barrier B:

class Barrier extends Thread { public Barrier(int n) {this.n = n;}

public void waitB() {arrive.send(); block.send(); }

public void run() { /* receive calls to ports arrive and block */ } private selectablePort arrive = new selectablePort();

private selectablePort block = new selectablePort();

}

Inside method waitB(), a call to arrive.send() signals a thread’s arrival at the barrier. The call to block.send() blocks the threads until all n threads have arrived at the barrier. Assume that the message queues for ports are FCFS. Implement method run() using a selective wait statement.

5.3.In Exercise 4.8 you were asked to write a monitor implementation of the unisex bathroom problem. Here you are asked to write an implementation using send() and receive() operations on selectablePorts.

(a)Implement the strategy in Exercise 4.8, part (a).

(b)Implement the strategy in Exercise 4.8, part (b).

Your implementation should complete the run() method below. Provide expressions for the guards, and implement the body for each of the four cases. Remember that a call to E.count() returns the number of messages that are waiting to be received for port E.

public void run() { try {

selectiveWait select = new selectiveWait();

womenEnter.guard(/* TBD */); womenExit.guard(/* TBD */); int choice = select.choose(); switch (choice) {

case 1: menEnter.receive(); /* ...; TBD; ...; */ break; case 2: menExit.receive(); /* ...; TBD; ...;*/ break; case 3: womenEnter.receive(); /* ...; TBD; ...; */ break;

case 4: womenExit.receive(); /* ...; TBD; ...; */ break;

}

}

} catch (InterruptedException e) {}

}

5.4.The bear and the honeybees (see Exercise 3.13). Solve this problem using selectablePorts and a selective wait statement. The bear calls port eat to eat the honey. The bees call port fillPot. Your implementation should complete the run() method below. Provide expressions for the guards, and implement the body for both cases.

public void run() { try {

selectiveWait select = new selectiveWait();

eat.guard(/* TBD */); fillPot.guard(/* TBD */); int choice = select.choose(); switch (choice) {

case 1: eat.receive(); /* ...; TBD; ...; */ break; case 2: fillPot.receive(); /* ...; TBD; ...;*/ break;

}

}

} catch (InterruptedException e) {}

}

5.5.This exercise compares if-else statements and selective wait statements.

(a)Consider the following if-else statement:

if (condition) // this can be any condition (e.g., A > 0) E1.receive();

else E2.receive();

Show how to simulate this if-else statement by using a selectiveWait. If you cannot write an exact simulation, explain why.

(b) Consider the following if-else statement:

E1.receive();

Show how to simulate this if-statement by using a selectiveWait. If you cannot write an exact simulation, explain why.

5.6.An else alternative of a selective wait is selected if (1) there are no other open alternatives (i.e., no alternatives with a true guard), or (2) at least one open alternative exists, but no messages are waiting for the open alternatives. Assume that the other alternatives are accept alternatives for ports E1, E2, . . . , En. Is (2) equivalent to the following condition? If not, try to correct this condition:

(!E1.guard() || E1.Count()==0) && (!E2.guard() || E2.Count()==0) && ...

&&(!En.guard() || En.Count()==0)

5.7.An implementation of readers and writers strategy R>W.1 is given below. Modify this implementation of R>W.1 to implement the following three strategies:

(a)R<W.1: Many readers or one writer, with writers having a higher priority.

(b)R<W.2: Same as R<W.1, except that when a writer requests to write, if no writer is writing or waiting, it waits until all readers that issued earlier requests have finished reading.

(c)R<W.3: Same as R<W.1 except that at the end of writing, waiting readers have a higher priority than waiting writers (see Exercise 4.9).

Strategies R<W.1 and R<W.2 differ as follows. Assume that when writer W1 arrives, reader R1 is reading and another reader, R2, has requested to read but has not started reading. R<W.1 lets W1 start before R2, while R<W.2 lets W1 start after R2. For R<W.1 and R<W.2, readers starve if before a writer finishes writing, the next writer requests to write.

In strategy R<W.3, at the end of a writing, waiting readers have higher priority than waiting writers. Note that waiting readers are readers that have already requested to read and are waiting when the write completes, not readers who request to read after the write completes. This strategy does not create starving readers or writers. A waiting writer does not starve since the number of readers allowed to proceed at the end of each write is finite. A waiting reader does not starve since it will be allowed to proceed before the writers that request to write after this reader.

The R>W.1 implementation contains a timestamp that you can use in strategies R<W.2 and R<W.3 to order the requests (i.e., determine whether a request was issued earlier or later than another request).

import java.util.*;

final class requestMessage {

public requestMessage(int ID, boolean isRead) {this.ID = ID;

5.8.In Section 5.5.2 we say that if program CP uses only links for communication and no selective wait statements, there is no nondeterminism that needs to be controlled during replay. But the implementation of class link uses P() and V() operations on semaphores. Chapter 3 describes a replay method for semaphores. Why is it that the P() and V() operations in the link class do not need to be controlled during replay?

Figure 6.1 Sockets are the endpoints of channels across a network.

no longer be implemented as regular program objects. Instead, channels will be formed across a communications network, with help from the operating system.

When two threads want to exchange messages over a channel, each thread creates an endpoint object that represents its end of the network channel. The operating system manages the hardware and software that is used to transport messages between the endpoints (i.e., “across the channel”). These endpoint objects are called sockets (Fig. 6.1):

žThe client thread’s socket specifies a local I/O port to be used for sending messages (or the I/O port can be chosen by the operating system). The client’s socket also specifies the address of the destination machine and the port number that is expected to be bound to the server thread’s socket.

žThe server’s socket specifies a local I/O port for receiving messages. Messages can be received from any client that knows both the server’s machine address and the port number bound to the server’s socket.

žThe client issues a request to the server to form a connection between the two sockets. Once the server accepts the connection request, messages can be passed in either direction across the channel.

6.1.1 Channel Reliability

Messages that travel across a network may be lost or corrupted, or they may arrive out of order. Some applications may be able to tolerate this. For example, if the data being sent across the network represents music, losing a message may create only a slight distortion in the sound. This might sound better to the listener than a pause in the music while lost messages are resent.

An application can choose how reliably its messages are transmitted by selecting a transport protocol:

žTransmission Control Protocol (TCP) ensures the reliable transmission of messages. TCP guarantees that messages are not lost or corrupted and that messages are delivered in the correct order. However, this adds some overhead to message transport.

žUser Data Protocol (UDP) is a fast but unreliable method for transporting messages. Messages sent using UDP will not be corrupted, but they may be lost or duplicated, and they may arrive in an order different from the order

in which they were sent. If this is not acceptable, the application must take care of error handling itself, or use TCP instead.

Both TCP and UDP utilize the Internet Protocol (IP) to carry packets of data. The IP standard defines the packet format, which includes formats for specifying source and destination addresses and I/O ports.

6.1.2 TCP Sockets in Java

The java.net class library provides classes Socket and ServerSocket for TCPbased message passing.

Class Socket We will use a simple client and server example to illustrate the use of TCP sockets in Java. A client’s first step is to create a TCP socket and try to connect to the server:

The client assumes that the server is listening for TCP connection requests on port serverPort. The Socket constructor throws an IOException if it cannot make a connection.

When the client’s request is accepted, the client creates an input stream to receive data from its socket and an output stream to send data to the socket at the server’s end of the channel. To the programmer, sending and receiving messages using TCP sockets looks just like reading and writing data from files:

PrintWriter toServer = new PrintWriter(socket.getOutputStream(),true); BufferedReader fromServer = new BufferedReader(new inputStreamReader

System.out.println ("Client received: "+ line + ‘‘ from Server’’); toServer.close(); fromServer.close(); socket.close();

A read operation on the InputStream associated with a Socket normally blocks. It is possible to set a timeout so that a read operation will not block for more