DURGA SOFTWARE SOLUTIONS

Page: 9

9. Multi-Threading

34. A ssume you have a class that holds two private variables: a and b. Which of the following pairs can prevent concurrent access problems in that class? (Choose all that apply.)
A. public int read(){return a+b;}
public void set(int a, int b){this.a=a;this.b=b;}
B. public synchronized int read(){return a+b;}
public synchronized void set(int a, int b){this.a=a;this.b=b;}
C. public int read(){synchronized(a){return a+b;}}
public void set(int a, int b){synchronized(a){this.a=a;this.b=b;}}
D. public int read(){synchronized(a){return a+b;}}
public void set(int a, int b){synchronized(b){this.a=a;this.b=b;}}
E. public synchronized(this) int read(){return a+b;}
public synchronized(this) void set(int a, int b){this.a=a;this.b=b;}
F. public int read(){synchronized(this){return a+b;}}
public void set(int a, int b){synchronized(this){this.a=a;this.b=b;}}
Answer:
-> B and F are correct. By marking the methods as synchronized, the threads will get the lock of the this object before proceeding. Only one thread will be setting or reading at any given moment, thereby assuring that read() always returns the addition of a valid pair.
-> A is incorrect because it is not synchronized; therefore, there is no guarantee that the

values added by the read() method belong to the same pair. C and D are incorrect; only objects can be used to synchronize on. E fails— it is not possible to select other objects (even this) to synchronize on when declaring a method as synchronized.

35. Which are methods of the Object class? (Choose all that apply.)
A. notify();
B. notifyAll();
C. isInterrupted();
D. synchronized();
E. interrupt();
F. wait(long msecs);
G. sleep(long msecs);
H. yield();
Answer:
-> A , B, and F are correct. They are all related to the list of threads waiting on the
specified object.
-> C, E, G, and H are incorrect answers. The methods isInterrupted() and interrupt()are instance methods of Thread. The methods sleep() and yield() are static methods of Thread. D is incorrect because synchronized is a keyword and the synchronized()construct is part of the Java language. (Objective 4.2)

36. Given the following
1. public class WaitTest {
2. public static void main(String [] args) {
3. System.out.print("1 ");
4. synchronized(args){
5. System.out.print("2 ");
6. try {
7. args.wait();
8. }
9. catch(InterruptedException e){}
10. }
11. System.out.print("3 ");
12. } }
What is the result of trying to compile and run this program?
A. It fails to compile because the IllegalMonitorStateException of wait() is not dealt with inline 7.
B. 1 2 3
C. 1 3
D. 1 2
E. At runtime, it throws an IllegalMonitorStateException when trying to wait.
F. It will fail to compile because it has to be synchronized on the this object.

Answer:
-> D is correct. 1 and 2 will be printed, but there will be no return from the wait call because no other thread will notify the main thread, so 3 will never be printed. It's frozen at line 7.
-> A is incorrect; IllegalMonitorStateException is an unchecked exception. B and C are incorrect; 3 will never be printed, since this program will wait forever. E is incorrect because IllegalMonitorStateException will never be thrown because the wait()is done on args within a block of code synchronized on args. F is incorrect because any object can be used to synchronize on and this and static don't mix.

37. Assume the following method is properly synchronized and called from a thread A on an object B:
wait(2000);
After calling this method, when will the thread A become a candidate to get another turn at the CPU?
A. After object B is notified, or after two seconds.
B. After the lock on B is released, or after two seconds.
C. Two seconds after object B is notified.
D. Two seconds after lock B is released.
Answer:
-> A is correct. Either of the two events will make the thread a candidate for running again.
-> B is incorrect because a waiting thread will not return to runnable when the lock is

released, unless a notification occurs. C is incorrect because the thread will become a
candidate immediately after notification. D is also incorrect because a thread will not come out of a waiting pool just because a lock has been released.

38. Which are true? (Choose all that apply.)
A. The notifyAll() method must be called from a synchronized context.
B. To call wait(), an object must own the lock on the thread.
C. The notify() method is defined in class java.lang.Thread.
D. When a thread is waiting as a result of wait(), it release its lock.
E. The notify() method causes a thread to immediately release its lock.
F. The difference between notify() and notifyAll() is that notifyAll() notifies all
waiting threads, regardless of the object they're waiting on.
Answer:
-> A is correct because notifyAll() (and wait() and notify()) must be called from within a synchronized context. D is a correct statement.
-> B is incorrect because to call wait(), the thread must own the lock on the object that wait() is being invoked on, not the other way around. C is wrong because notify() is defined in java.lang.Object. E is wrong because notify() will not cause a thread to release its locks. The thread can only release its locks by exiting the synchronized code. F is wrong because notifyAll() notifies all the threads waiting on a particular locked object, not all threads waiting on any object.

39. Given the scenario: This class is intended to allow users to write a series of messages, so that each message is identified with a timestamp and the name of the thread that wrote the message:
public class Logger {
private StringBuilder contents = new StringBuilder();
public void log(String message) {
contents.append(System.currentTimeMillis());
contents.append(": ");
contents.append(Thread.currentThread().getName());
contents.append(message);
contents.append("\n");
}
public String getContents() { return contents.toString(); }
}
How can we ensure that instances of this class can be safely used by multiple threads?
A. This class is already thread-safe.
B. Replacing StringBuilder with StringBuffer will make this class thread-safe.
C. Synchronize the log() method only.
D. Synchronize the getContents() method only.
E. Synchronize both log() and getContents().
F. This class cannot be made thread-safe.
Answer:
-> E is correct. Synchronizing the public methods is sufficient to make this safe, so F is false.
This class is not thread-safe unless some sort of synchronization protects the changing data.

-> B is not correct because although a StringBuffer is synchonized internally, we call append() multiple times, and nothing would prevent two simultaneous log() calls from mixing up their messages. C and D are not correct because if one method remains unsynchronized, it can run while the other is executing, which could result in reading the contents while one of the messages is incomplete, or worse. (You don't want to call getString() on the StringBuffer as it's resizing its internal character array.)

40. Given:
public static synchronized void main(String[] args) throws
InterruptedException {
Thread t = new Thread();
t.start();
System.out.print("X");
t.wait(10000);
System.out.print("Y");
}
What is the result of this code?
A. It prints X and exits.
B. It prints X and never exits.
C. It prints XY and exits almost immeditately.
D. It prints XY with a 10-second delay between X and Y.
E. It prints XY with a 10000-second delay between X and Y.
F. The code does not compile.
G. An exception is thrown at runtime.
Answer:
-> G is correct. The code does not acquire a lock on t before calling t.wait(), so it throws an IllegalThreadStateException. The method is synchronized, but it's not synchronized on t so the exception will be thrown. If the wait were placed inside a synchronized(t) block, then the answer would have been D.
-> A, B, C, D, E, and F are incorrect based the logic described above.

Page: 9

1 2 3 4 5 6 7 8 9 10