Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

What exactly happens in a call to Object.wait()  RSS feed

 
Ajay Saxena
Ranch Hand
Posts: 154
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi ranchers,

This question keeps boggling me as there's no explicit mention of what exactly happens at the OS level when a thread is made to 'wait' by a call to Object.wait() in the JDK documentation.

I understand that when wait() is called, the current thread relinquishes control of the lock on the monitor of the object on which the wait() has been called and that the wait() method would return only after the current thread has been awakened (through notification by some other thread)and has RE-acquired the released lock.

Now, when a thread is lying in the waiting state , we say that it's blocked. While it remains blocked, does it get suspended (swapped out of main memory and written to some secondary storage)? Or does it just remain in the main memory as the JVM process is still in the main memory?
I feel the underlying waiting OS thread should be in the main memory but in the blocked state and not swapped out to the disk,because the parent process(JVM) is still in the main memory.
I'm assuming that we have at least two threads in the JVM.

Do share your knowledge/views/opinions on this.

-thanks
san ban

[ December 03, 2007: Message edited by: san ban ]
[ December 04, 2007: Message edited by: san ban ]
 
Nitesh Kant
Bartender
Posts: 1638
IntelliJ IDE Java MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
he wait() method would return only after the current thread has been awakened (through notification by some other thread)and has RE-acquired the released lock

The statement in bold is not correct. Wait method returns after a notification/expiration of timed wait/spurious wake-up and after that the thread competes for the monitor as it would have done before entering the synchronization block.


Can you clarify as to what you are referring to as a secondary storage?
<CorrectMeIfIAmWrong>
Generally, secondary storage is used for a persistance store like hard disk. </CorrectMeIfIAmWrong>
 
Ajay Saxena
Ranch Hand
Posts: 154
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Nitesh Kant:
The statement in bold is not correct. Wait method returns after a notification/expiration of timed wait/spurious wake-up and after that the thread competes for the monitor as it would have done before entering the synchronization block.


I don't think I agree with you. Refer to the following from JDK Doc

The wait() method causes a thread to wait until it is notified by another thread to stop waiting. When wait() is called, the thread releases its lock on this object and waits until another thread notifies it to wake up through a call to either notify() or notifyAll(). After the thread is awakened, it has to regain the lock on this object before it can resume executing.

How can we have the wait() method return and still have the thread that called it waiting till the former regains the lock on the monitor? This seems lil counterintuitive to me.

And by secondary storage here, I mean disk storage i.e. external memory
[ December 03, 2007: Message edited by: san ban ]
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24215
37
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
First: yes, when wait() returns, the calling thread has re-acquired the lock on the object.

Second: what happens at an OS level depends on 1) the OS, and how (or if) it implements threading, and 2) the JVM implementation, and how it makes use of the OS primitives that are available. Therefore the strictest answer to your question is "it's implementation-dependent."

The real answer, though, is that no OS I'm aware of, nor any JVM, implement thread suspension (or process suspension, for that matter) by unconditionally swapping the thread (or process) out to disk. That would be extremely inefficient; threads and processes share your processor in time-slices that can last only tens of milliseconds or even less; swapping everything out to disk whenever it was not running would slow the machine down enormously.

On an OS that has virtual memory, then memory pages used only by a suspended thread may indeed be written out to disk if the RAM needs to be reused; but this isn't really a thread-specific issue. Memory that isn't actively being used can be paged out until it is needed again.
 
Ajay Saxena
Ranch Hand
Posts: 154
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the explanation Ernest! This is exactly what I was looking for..
 
Nitesh Kant
Bartender
Posts: 1638
IntelliJ IDE Java MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, if you see the javadocs, it is not very clear as to whether the regaining of lock happens from withing the wait() method or after it. It just says that the thread has to wait to regain the lock after notification.
However, the following from the java langauge specifications clears my doubt:

Wait actions occur upon invocation of wait(), or the timed forms wait(long millisecs) and wait(long millisecs, int nanosecs). A call of wait(long millisecs) with a parameter of zero, or a call of wait(long millisecs, int nanosecs) with two zero parameters, is equivalent to an invocation of wait().

A thread returns normally from a wait if it returns without throwing an InterruptedException.

Let thread t be the thread executing the wait method on object m, and let n be the number of lock actions by t on m that have not been matched by unlock actions. One of the following actions occurs.

* If n is zero (i.e., thread t does not already possess the lock for target m) an IllegalMonitorStateException is thrown.
* If this is a timed wait and the nanosecs argument is not in the range of 0-999999 or the millisecs argument is negative, an IllegalArgumentException is thrown.
* If thread t is interrupted, an InterruptedException is thrown and t's interruption status is set to false.
* Otherwise, the following sequence occurs:

1. Thread t is added to the wait set of object m, and performs n unlock actions on m.
2. Thread t does not execute any further instructions until it has been removed from m's wait set. The thread may be removed from the wait set due to any one of the following actions, and will resume sometime afterward.
* A notify action being performed on m in which t is selected for removal from the wait set.
* A notifyAll action being performed on m.
* An interrupt action being performed on t.
* If this is a timed wait, an internal action removing t from m's wait set that occurs after at least millisecs milliseconds plus nanosecs nanoseconds elapse since the beginning of this wait action.
* An internal action by the implementation. Implementations are permitted, although not encouraged, to perform "spurious wake-ups" -- to remove threads from wait sets and thus enable resumption without explicit instructions to do so. Notice that this provision necessitates the Java coding practice of using wait only within loops that terminate only when some logical condition that the thread is waiting for holds.

Each thread must determine an order over the events that could cause it to be removed from a wait set. That order does not have to be consistent with other orderings, but the thread must behave as though those events occurred in that order.

For example, if a thread t is in the wait set for m, and then both an interrupt of t and a notification of m occur, there must be an order over these events.

If the interrupt is deemed to have occurred first, then t will eventually return from wait by throwing InterruptedException, and some other thread in the wait set for m (if any exist at the time of the notification) must receive the notification. If the notification is deemed to have occurred first, then t will eventually return normally from wait with an interrupt still pending.
3. Thread t performs n lock actions on m.
4. If thread t was removed from m's wait set in step 2 due to an interrupt, t's interruption status is set to false and the wait method throws InterruptedException.


Apologies for the wrong post.
 
Ajay Saxena
Ranch Hand
Posts: 154
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Never mind Nitesh and thanks a lot for the execellent piece of information. It beautifully explains the complete mechanics of the wait().I tried to lay my hands on something similar

Java ranch really rocks
[ December 04, 2007: Message edited by: san ban ]
 
Nitesh Kant
Bartender
Posts: 1638
IntelliJ IDE Java MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have quoted the above from the Java language specifications in case you are interested reading them.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!