Answer : Option A

Explanation :

Option A is correct because the notifyAll() method (along with wait() and notify()) must always 

be called from within a synchronized context.

Option 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.

Option C is wrong because notify() is defined in java.lang.Object.

Option D 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.

Answer : Option C

Explanation :

The class correctly implements the Runnable interface with a legal public void run() method.

Option A is incorrect because interfaces are not extended; they are implemented.

Option B is incorrect because even though the class would compile and it has a valid public 

void run() method, it does not implement the Runnable interface, so the compiler would complain 

when creating a Thread with an instance of it.

Option D is incorrect because the run() method must be public.

Answer : Option C

Explanation :

Statements (4) and (6) are correct. (4) is correct because the wait() method is overloaded to 

accept a wait duration in milliseconds. If the thread has not been notified by the time the wait 

duration has elapsed, then the thread will move back to runnable even without having been 

notified.

(6) is correct because wait()/notify()/notifyAll() must all be called from within a synchronized, 

context. A thread must own the lock on the object its invoking wait()/notify()/notifyAll() on.

(1) is incorrect because wait()/notify() will not prevent deadlock.

(2) is incorrect because a sleeping thread will return to runnable when it wakes up, but it might 

not necessarily resume execution right away. To resume executing, the newly awakened thread 

must still be moved from runnable to running by the scheduler.

(3) is incorrect because synchronization prevents two or more threads from accessing the same

 object.

(5) is incorrect because notify() is not overloaded to accept a duration.

Answer : Option B

Explanation :

Option B is correct - The notify method only wakes the thread. It does not guarantee that the 

thread will run.

Option A is incorrect - just because another thread activates the modify method in A this does 

not mean that the thread will automatically resume execution

Option C is incorrect - This is incorrect because as said in Answer B notify only wakes the thread 

but further to this once it is awake it goes back into the stack and awaits execution therefore it is 

not a "direct and sole consequence of the notify call"

Option D is incorrect - The notify method wakes one waiting thread up. If there are more than one 

sleeping threads then the choice as to which thread to wake is made by the machine rather than 

you therefore you cannot guarantee that the notify'ed thread will be the first waiting thread.

Answer : Option C

Explanation :

There are two ways of creating a thread; extend (sub-class) the Thread class and implement the Runnable interface. For both of these ways you must implement (override and not overload) 

the public void run() method.

(1) is correct - Extending the Thread class and overriding its run method is a valid procedure.

(4) is correct - You must implement interfaces, and runnable is an interface and you must also

 include the run method.

(2) is wrong - Runnable is an interface which implements not Extends. Gives the error: (No 

interface expected here)

(3) is wrong - You cannot implement java.lang.Thread (This is a Class). (Implements Thread, 

gives the error: Interface expected). Implements expects an interface.

(5) is wrong - You cannot implement java.lang.Thread (This is a class). You Extend classes, 

and Implement interfaces. (Implements Thread, gives the error: Interface expected)