Introduction / Context:
The item asks you to evaluate several assertions about Java’s wait/notify mechanism and thread scheduling. Understanding which methods are overloaded, what contexts are required, and what guarantees exist is essential for correct concurrent code.
Given Data / Assumptions (statements):
- 1) Deadlock will not occur if wait()/notify() is used
- 2) A thread will resume execution as soon as its sleep duration expires.
- 3) Synchronization can prevent two objects from being accessed by the same thread.
- 4) The wait() method is overloaded to accept a duration.
- 5) The notify() method is overloaded to accept a duration.
- 6) Both wait() and notify() must be called from a synchronized context.
Concept / Approach:
Evaluate each statement against the Java Language Specification and java.lang.Object API.
Step-by-Step Solution:
1) False. Deadlock is still possible if locks are acquired in conflicting orders or notifications are missed due to logic errors.2) False. sleep sets the thread to TIMED_WAITING; after the time elapses it becomes RUNNABLE, but scheduling is not guaranteed immediately.3) False. Synchronization restricts concurrent access by multiple threads to shared state; it does not prevent a thread from accessing two objects.4) True. Object.wait has overloads: wait(long) and wait(long, int) besides wait().5) False. notify() and notifyAll() have no timed overloads.6) True. A thread must own the monitor to call wait/notify; otherwise IllegalMonitorStateException is thrown.
Verification / Alternative check:
Consult Object’s method signatures: wait(), wait(long), wait(long, int), notify(), notifyAll().
Why Other Options Are Wrong:
- Any pair containing 1, 2, 3, or 5 includes at least one false statement.
Common Pitfalls:
Believing that sleep guarantees immediate resumption or that using wait/notify magically prevents deadlocks.
Final Answer:
4 and 6
Discussion & Comments