java: wait(), notify() and synchronized blocks
Asked Answered
A

4

8

I learned that calling an Object's wait() method will release the object monitor, if present.

But I have some questions regarding calling notify() on this object by another thread:

  1. (when) will the waiting thread wake up, if another (a 3rd) thread owns the object monitor in the meanwhile?

  2. will the waiting thread wake up, if a 3rd thread called wait() on this object?

  3. is it possible to determine if a thread is waiting for notifying a particular object (java 1.4/java 5)

  4. What's happening if wait() will be called in the finalize() method?

Aney answered 6/7, 2010 at 21:57 Comment(0)
C
2
  1. notify will wake one thread waiting on the monitor. Unless and until the monitor is unowned, no thread waiting can run; wait() must be called in a synchronized block and so the lock must be held to continue running that block.
  2. No guarantees. Call notifyAll to give all threads a chance to wake.
  3. Dunno. You could have the thread set a variable saying it's waiting before it goes to sleep...
  4. This is probably a bad idea. Can you come up with a situation where this is necessary?
Clariceclarie answered 6/7, 2010 at 22:11 Comment(2)
1. "wait() must be called in a synchronized block" is wrong. But it should. 2. Yes you're right. 3. I think Chris Denett is right here. Thread.holdsLock() sounds good. 4. It was more a theoretical question to understand the concepts.Aney
@MRalwasser: Disagree, it must. Have a look here: #2779984Pyrrhic
M
3

When you call wait() from a thread, that thread stop executing and it's added to the waitset of the object. When you call notify() from another thread, a random thread from the waitset is waked up, if you call notifyAll() all would be ready to execute.

When you call notify(), the thread is ready to run but it doesnt mean it will be executed inmediately so be careful.

  1. It would wake up a thread from the waitset randomly.

  2. Youd don't know which one will be waked up first, it doesn't follow any order.

  3. Thread.getState()

  4. You would produce deadlock.

Mameluke answered 6/7, 2010 at 22:14 Comment(0)
A
2
  1. That's why you have the notify() and notifyAll() methods. The former wakes up one thread waiting on the object, the latter wakes up all threads. A waiting thread will not wake up if wait() is called in another thread.

  2. No.

  3. It's only possible to call thread.holdsLock(obj) to see if a thread holds the monitor lock on a particular object.

  4. Don't call wait() in a finalize method.

Audette answered 6/7, 2010 at 22:10 Comment(1)
I accept 2.-4. but your answer to 1. is wrong. I am talking about lock monitor (synchronized blocks)Aney
C
2
  1. notify will wake one thread waiting on the monitor. Unless and until the monitor is unowned, no thread waiting can run; wait() must be called in a synchronized block and so the lock must be held to continue running that block.
  2. No guarantees. Call notifyAll to give all threads a chance to wake.
  3. Dunno. You could have the thread set a variable saying it's waiting before it goes to sleep...
  4. This is probably a bad idea. Can you come up with a situation where this is necessary?
Clariceclarie answered 6/7, 2010 at 22:11 Comment(2)
1. "wait() must be called in a synchronized block" is wrong. But it should. 2. Yes you're right. 3. I think Chris Denett is right here. Thread.holdsLock() sounds good. 4. It was more a theoretical question to understand the concepts.Aney
@MRalwasser: Disagree, it must. Have a look here: #2779984Pyrrhic
N
0

2: Not necessarily. notify() wakes up one of the waiting threads. It might be the original one or the third one.

3: Using thread.getState() you can find out if a thread is waiting for an object, but I don't know if you can always find out which object this is, exactly.

Nogas answered 6/7, 2010 at 22:10 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.