• Post Reply Bookmark Topic Watch Topic
  • New Topic

question on wait()

 
Arul Jose
Ranch Hand
Posts: 131
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

in the given code, when the thread comes to line 9, it has already got the lock of b, why should it then wait for the lock of b?
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24213
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
wait() doesn't wait for the lock; it actually releases the lock. What it's doing is waiting for some other thread to call notify() on that same locked object. This wait() is one-half of the inter-thread communications mechanism. Before wait() returns, the calling thread re-acquires the lock.

Note that this is bad code -- wait() should always be called in a loop, since wait() may returns due to an interrupt() call rather than a notify(), or some thread may call notify() for the wrong reason. Usually you'll see something like

 
Arul Jose
Ranch Hand
Posts: 131
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
why should b release its lock before finishing operations?
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24213
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Arul Jose:
why should b release its lock before finishing operations?


wait() releases the lock so that some other thread can grab the lock, do whatever the original thread is waiting for while holding the lock, notify the object so the original thread knows that work is done, and then release the lock so wait() can get it back.
 
Henry Wong
author
Sheriff
Posts: 22519
109
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Another point -- which I always like to make -- is that this somewhat integrated convoluted dance (of releasing and grabbing locks) is not the invention of Java.

This is the same technique used by Solaris threads, POSIX (including Linux)threads, and Windows threads -- with their mutex locks and condition variables.

There is a race condition with setting flags (or any other value) and sending notifications, that can't be solved unless the condition variable does the locking (release and reacquire) in an integrated manner.

Henry
 
Arul Jose
Ranch Hand
Posts: 131
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
First of all thanks for your answers.

wait() releases the lock so that some other thread can grab the lock, do whatever the original thread is waiting for


1. so, only when the current thread is waiting for some other thread's execution, the wait() method is called?

2. so the method wait() waits till the current thread gets a notification?

3. if it doesn't get notified, it will keep waiting?

4. when a thread says notify() there is no guarantee that the thread which we are expecting will get notified right? so if the original thread gets a notify from some other unexpected thread, the original thread may run before the 'other thread'(which it is waiting for to finish some operation) finishes operation right? so what is the point in saying wait()?

to explain thread A is saying wait() expecting B to say notify(). what if some other thread C says notify() before B says notify() and A gets notified?

ARUL JOSE
 
Henry Wong
author
Sheriff
Posts: 22519
109
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1. I guess. However, we can also use wait() as a sleep() while not holding a lock (see timeout version).

2. Yes... well, you can also use a timeout. Or get interrupted.

3. Yes.

4. This is why object choice is very important. When you design an program with two threads. You should not choose an object to call wait() on, that is used by other threads.

4a. This is why notifications should not be used blindly. When a notification is sent, the waking thread should check to see if the state is actually in a acceptable state and go back to waiting otherwise -- the check must be done with the lock.

Henry
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!