CODEWITHSUNDEEP
javamultithreadingoperating-system
Nishat
Nishat

Reputation: 919

CPU cycle for object.wait and Thread.sleep()

How does behaviour of CPU cycle different for Wait and sleep. As per Thread life cycle diagram It is clear that If Thread.sleep() or object.wait is called,running thread will be pushed in blocking state,during this blocking state CPU cycle will not be used.

If I am correct then why not any body mentioned this in Difference between wait() and sleep()

Please correct me if I am wrong.

Also,As per my understanding when Thread.sleep(t) is called,after time t,interrupt signal is generated to consider this task also for next cpu cycle.what happens in case of object.wait()? does interrupt is also generated for object.wait()?

Upvotes: 2

Views: 1933

Answers (2)

Stephen C
Stephen C

Reputation: 718788

If I am correct then why not any body mentioned this in Difference between wait() and sleep()

(You are correct.)

  1. Because that is the same in both cases is not a difference. The Q & A's you have linked to ask about the differences between sleep and wait.

  2. Presumably because the authors of the specific answers that you read didn't think it was relevant to what they were saying. Or because they thought it was obvious.

Also,As per my understanding when Thread.sleep(t) is called,after time t,interrupt signal is generated to consider this task also for next cpu cycle.what happens in case of object.wait()? does interrupt is also generated for object.wait()?

I presume you are talking about hardware interrupts here, because no Java interrupts are involved.

The answer is that it is way more complicated than you think. The timers that are used to terminate Java sleep and timed wait calls may or may not be implemented using hardware interrupts. That is OS specific. But if they are, I would expect the OS to implement them both the same way. (Because the functional requirements are pretty similar).

The broad brush implementation would be something like this:

  1. Java makes syscall via native code. The syscall request either:

    • wake me after N milliseconds, or
    • wake me when notified or after N milliseconds
  2. The OS schedules a "wakeup" for N milliseconds time
  3. The OS marks the native thread as blocked
  4. After approximately N milliseconds, the OS timer (or whatever) unblocks the native thread; i.e. it becomes runnable

  5. Immediately, or sometime later, the OS thread scheduler schedules it to a core and the thread runs.

    • for a sleep, the Java thread just runs
    • for a timed wait, the Java runtime either generates and throws an InterruptedException, or it tries to reacquire the mutex, etcetera. The latter may block again.

There are multiple ways that the OS could implement "wake up after N" milliseconds. Some of the strategies are:

  • Use a separate hardware timer for each wakeup. This doesn't scale, since hardware times are a finite / limited resource.
  • Use a single hardware timer for all wakeups. In effect, the timer is set for the earliest of future wakeups.
  • Set a hardware timer to trigger once every C milliseconds, and consider wakeups at those points.

For the precise details, you will need to download and read OpenJDK source code AND the source for the OS. Also, the details are liable to be different for different versions of Java and different versions of the OS.

Upvotes: 4

Warren Dew
Warren Dew

Reputation: 8928

The question on the CPU thread state is answered at your link - both wait() and sleep() block the thread - so I'll only answer your last paragraph.

When you call Thread.sleep(t), the thread simply continues execution after time t; no Java InterruptedException is thrown and the interrupted state of the thread is not set. How this is handled at the virtual machine and hardware level, and how many CPU cycles, if any, are involved, depends on the particular platform and virtual machine implementation.

Both Thread.sleep() and Object.wait() throw InterruptedException if Thread.interrupt() is called on the thread.

Upvotes: 0

Related Questions