2

These are a few conceptual doubts.

I read this in a book while preparing for SCJP

Just because a thread’s sleep() expires, and it wakes up, does not mean
it will return to running. It simply goes back to the runnable state.
So you can't rely on sleep() for an accurate timer.

Say I have threads t1 and t2 and an object obj1.

1) I have called sleep() for 5 seconds on t1 which was doing some work on obj1. There is still some work pending to do by t1 on obj1. sleep() does not release the lock on obj1. At the same time t2 is trying to access obj1.

But if there is no guarantee that t1 will get running again, could such a situation arise where t2 would keep on waiting forever? Could such a situation be avoided?

2) If t1 is making changes to obj1 according to its task, and in between I call wait() on t1. t2 steps in and makes changes to obj1 according to its work.

When t1 gets running again, it would be a mess, right? Because the state of obj1 then would be whatever was done by t2, and t1 would lose all the work done by it before wait() was called.

3) wait() is a non-static method, so could one thread cause another thread to wait, if it has a reference of the other thread? Is there any example to understand this kind of application?

4) Also I read something that wait() has to be called from a synchronized context, and it's a bad idea to call sleep() from a synchronized context. What is the reason for both of these?

Jeet Parekh
  • 740
  • 2
  • 8
  • 25

2 Answers2

1

Difference between wait and sleep in Java :

  1. wait release lock on object while waiting while sleep doesn't release lock while waiting.
  2. wait is normally done on condition, Thread wait until a condition is true while sleep is just to put your thread on sleep.
  3. wait is called from synchronized context only while sleep can be called without synchronized block. see Why wait and notify needs to call from synchronized method for more detail.
  4. wait is called on Object while sleep is called on Thread. see Why wait and notify are defined in object class instead of Thread.
  5. waiting thread can be awake by calling notify and notifyAll while sleeping thread can not be awaken by calling notify method.
Ragu
  • 373
  • 5
  • 15
  • All true, but you didn't say how either one of them was meant to be used. `Thread.sleep()` is meant for timing. It is the primitive operation that underlies `ScheduledThreadPoolExecutor` and any other higher-level facility that makes things happen at specified times. `Object.wait()` and `Object.notify()` are meant for communication between threads. They are the lowest-level mechanism that one thread can use to tell another, "I have done the thing that you are waiting for." – Solomon Slow May 27 '15 at 12:27
1

Alright I'm going to try to answer this.

  1. If t1 never gets to run again, I'd say the kernel's thread scheduler is broken. I don't know where you got your idea that it would never run again.

  2. If you have two threads making changes to one object, you need to make sure they behave properly. Such as using synchronized to make sure only one thread manipulates the object at a time. Your example is odd, because you seem to imply that the programmer doesn't decide what happens with the code.

  3. You don't understand wait() and notify(). Search for a question about them, there's plenty.

  4. wait() needs to be in synchronized context to get the object monitor. sleep() in synchronized context just creates an unnecessary block for other threads wanting to enter.

Kayaman
  • 72,141
  • 5
  • 83
  • 121
  • The first question was just a doubt of a possibility. Thanks for the answer – Jeet Parekh May 27 '15 at 07:23
  • @vicky96 - It is *discouraged* to use `sleep()` for *timing things* because the *interrupt might happen correctly* but the scheduler might not *schedule* the execution of the thread immediately. A sleeping thread will not be scheduled until the time elapses. – TheLostMind May 27 '15 at 07:28