THE UNIVERSITY OF WESTERN AUSTRALIA SAMPLE EXAM QUESTIONS 2007 WITH SOLUTIONS SCHOOL OF COMPUTER SCIENCE CITS3213 CONCURRENT PROGRAMMING (PART II)

Transcription

1 THE UNIVERSITY OF WESTERN AUSTRALIA SAMPLE EXAM QUESTIONS 2007 WITH SOLUTIONS SCHOOL OF COMPUTER SCIENCE CITS3213 CONCURRENT PROGRAMMING (PART II) The exam will contain: 6 questions (3 for each part) Time allowed : TWO HOURS TEN MINTUES Marks for the exam will total 60. Candidates should answer all SIX Questions. 4. (a) Explain the basic idea of a monitor. What is a condition variable in a monitor? Explain the Wait and Signal operations on a condition variable. How do monitors in Java differ from the standard concept of monitors? (6) I answered this in lectures. Also, see the first set of notes on monitors. (b) Would you like Java to support concurrency through semaphores instead of the present support through monitors? What kind of problems do you anticipate as a programmer if such a change is made? (4) A: No, because monitors are easier to program with, since they automatically enforce mutual exclusion in a way that follows the structure of a program. Also, the semaphore operations can easily be programmed using monitors and put in library, while the reverse is not true since using semaphores we cannot emulate the way monitors automatically follow the structure of the program. Semaphores will cause problems because they require that mutual exclusion be explicitly released, and forgetting a single such release will lead to the program deadlocking. Also, monitors are naturally re-entrant, while semaphores are not, and deadlocks will occur if a thread waits on a semaphore that it has already obtained.

2 5. (a) Explain clearly in your own words how Java implements Remote Method Invocation (RMI), including how objects are passed when they are parameters or return results of remote calls. (5) A: A server registers objects in a registry that accepts requests over the network. Each registered object is given a name. The client looks up this name, and is given a remote object reference for the server object. It uses this name to create a stub object (or proxy object) on the client, which is an object that forwards method calls to the actual object on the server via the network. When a method call is made on the stub object, it marshals the arguments into bytes and then sends them over the network to the server, along with the remote reference for the server object, and an identifier for the method being called. On the server, skeleton code receives this information, umarshals the arguments back to their original form, and makes the appropriate call to the actual server object. When this call completes, the skeleton code informs the client stub object, and sends any return value over the network in marshaled form. The client stub object then unmarshals the return value, and the original call to the client stub object returns appropriately. Objects may be marshalled either by local value or by remote reference. Passing by local value means that a clone of the object is created on the remote host, which is done by serializing the instance variables of the object into a series of bytes. Passing by remote reference means that the object remains on the same host, and has a remote reference created for it so that it can receive remote method calls from other host. Then, this remote reference is passed, and is unmarshaled at the other end by creating an appropriate stub object. (b) Explain how distributed snapshots can be used for distributed termination detection. What is it about termination that makes it a suitable property for checking using snapshots? (5) A: To use snapshots to detect termination, we need to periodically take a snapshot and check whether termination has occurred in the snapshot. Each snapshot is performed using the standard distributed snapshot algorithm. 2

3 This records a state for each host and some messages in transit for each communication channel. To detect termination, the state information for a host only needs to include whether that host is currently active or is ready to terminate. We detect that the whole system has terminated if in the snapshot all hosts are ready to terminate, and there are no messages in transit on any channel. Termination can be checked using snapshots because it is a stable property: once it becomes true, it stays true forever. That is, once the system has terminated, it stays terminated. This is important because the snapshot is only guaranteed to be a possible state that the system could have a gone through while the snapshot was being taking. Since termination is a stable property, we know that if we see termination in the snapshot, that the system must have terminated by the end of the snapshot. 6. Consider the following Java code for circular linked lists. public class CList extends Thread { private int item; private Clist next; private int updatecount=0; public synchronized void replace(int old, int neww, Clist startedat) { if(item==old) {item=neww; updatecount++; public void run() { for(int i=0; i<100; i++) replace(i, i-1, this); public Clist(int item, Clist next) { this.item=item; this.next=next; public static void main(string args[]) { Clist clist3 = new Clist(60, null); Clist clist2 = new Clist(40, clist3); Clist clist1 = new Clist(20, clist2); clist3.next = clist1; 3

4 clist1.start(); clist2.start(); clist3.start(); (a) Explain why it is possible for this code to deadlock. Include a description of a situation where a deadlock occurs. (4) A: This code may deadlock because clist1, clist2 and clist3 together form a cycle - repeatedly following the next instance variable leads back to the original CList object. The three threads each run replace, which will lock the object, then the next object, and then the third object. So, we can have a deadlock if two threads commence a call to replace at about the same time, since each will lock its own CList object, then then try to obtain locks on the other two CList objects. E.g., we can have the following sequence. thread 1: calls replace, obtains the lock on CList1 thread 2: calls replace, obtains the lock on CList2 thread 1: calls next.replace, waits for the lock on CList2 thread 2: calls next.replace, obtains the lock on CList3 thread 2: calls next.replace, waits for lock on CList1 DEADLOCKED (b) Show two different ways that this code may be fixed in order to avoid deadlocks. For each, show the code for the methods that need to be changed and also explain why deadlocks are no longer possible. (6) A: The deadlock may be resolved by using the class object lock, as follows. public void replace(int old, int neww, Clist startedat) { synchronized(clist.class) { if(item==old) {item=neww; updatecount++; 4

5 This code can no longer deadlock because any thread that holds the class object lock will be able to complete the original call to replace without waiting for any more locks, since it never waits for any other lock. So, it will eventually release the lock, and since this is the only lock other threads could be waiting for, they will eventually get to continue. Another way to fix this code is to reduce the duration that locks are held, as follows. public void replace(int old, int neww, Clist startedat) { synchronized(this) { if(item==old) {item=neww; updatecount++; This code cannot deadlock because threads only hold one lock at a time. So, if one thread is waiting for a lock held by a second thread, we know that the second thread only hold the lock for a short time (while executing the first if above), and in particular it will release the lock before it waits on another lock. Hence, the first thread will be able to obtain the lock and will not wait forever. END OF PAPER 5