Which of the following will NOT directly cause the calling thread to stop executing at that moment?

Java Programming Threads Difficulty: Easy
Choose an option
  • A
    notify()
  • B
    wait()
  • C
    Accessing an InputStream (e.g., read())
  • D
    sleep()
  • E
    None of the above

Answer

Correct Answer: notify()

Explanation

Introduction / Context:Blocking versus non-blocking operations are central to thread behavior. Some APIs suspend the caller; others signal different threads and let the caller continue.

Given Data / Assumptions:

  • We focus on the immediate effect on the current (calling) thread.
  • Assume correct monitor ownership for monitor methods.

Concept / Approach:wait() and sleep() suspend the current thread. Blocking I/O (such as InputStream.read()) can also suspend the caller until data becomes available. In contrast, notify() (and notifyAll()) wake other waiting threads but do not block or stop the caller.

Step-by-Step Reasoning:

notify(): caller continues → does not directly stop.wait(): caller releases monitor and blocks → stops.sleep(): caller sleeps → stops.InputStream access: may block → stops until data arrives.

Verification / Alternative check:Javadoc for Object and Thread confirms which calls are blocking or signaling.

Why Other Options Are Wrong:They are either blocking calls by design or can block in common scenarios (I/O).

Common Pitfalls:Assuming notify() transfers the lock or blocks the caller; it simply wakes others.

Final Answer:notify()

Discussion & Comments
No comments yet. Be the first to comment!
Join Discussion