We Keep Coding

How is java `wait()` waiting implemented? [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 4 years ago.
Improve this question
I'm asking about the waiting process not the access ordering method is it in the simplest form an infinite loop with a conditional exit.
Whats the least resource consuming way to wait for a request thats what got me to ask this.

Object.wait() functionality is implemented with JVM_MonitorWait native method, as per ThreadReference javadoc:
/** Thread is waiting - Object.wait() or JVM_MonitorWait() was called */
public final int THREAD_STATUS_WAIT = 4;
The implementation of this method can be found in jvm.cpp and uses ObjectSynchronizer::wait:
JVM_ENTRY(void, JVM_MonitorWait(JNIEnv* env, jobject handle, jlong ms))
JVMWrapper("JVM_MonitorWait");
Handle obj(THREAD, JNIHandles::resolve_non_null(handle));
JavaThreadInObjectWaitState jtiows(thread, ms != 0);
if (JvmtiExport::should_post_monitor_wait()) {
JvmtiExport::post_monitor_wait((JavaThread *)THREAD, (oop)obj(), ms);
// The current thread already owns the monitor and it has not yet
// been added to the wait queue so the current thread cannot be
// made the successor. This means that the JVMTI_EVENT_MONITOR_WAIT
// event handler cannot accidentally consume an unpark() meant for
// the ParkEvent associated with this ObjectMonitor.
}
ObjectSynchronizer::wait(obj, ms, CHECK);
JVM_END
ObjectSynchronizer::wait implementation is in synchronizer.cpp and delegates to ObjectMonitor::wait in objectMonitor.cpp.
If you continue to dig in you will eventually reach the native Java thread implementation which is platform dependent. On Linux this will be libpthread.so which will ultimately handle the thread status change.

is it in the simplest form an infinite loop with a conditional exit?
No it isn't. That is inefficient, and not how it is typically done.
The details are complicated and system dependent (see #Karol's answer for links to the code), but the general approach is as follows.
When the thread calls wait(), the method does the following:
Add the thread details to the mutex object's queue of "objects waiting".
Relinquish the thread's mutex lock.
"Park" the thread by telling the OS to put it to sleep.
The OS finds some other thread to schedule. If there is none, it causes the core to go into a low power "idle" loop or suspends it or something. (This is OS and hardware dependent.)
Then when another thread calls notify, the notify method does the following:
It removes a thread from the mutex queue.
It tells the OS that the (previously) waiting thread should be woken.
It returns from the notify() call and (hopefully) releases the mutex lock.
The OS does the following:
It finds a free processor to run the thread, and starts.
If no core is free, the OS adds the thread to the scheduler's queue of runnable threads.
When the thread starts, it first tries to reacquire the mutex lock ... which may cause it to be put back to sleep, if some other thread is still holding the lock.
Finally the wait call returns, and the thread will typically recheck the condition variable, and then release the lock.
The point is that there are (typically) no infinite loops that that consume CPU while a thread is waiting.
Whats the least resource consuming way to wait for a request that is what got me to ask this.
The least resource consuming way would be Object.wait and Object.notify ...

In synchronous programing, a monitor can be assumed like a box or more specifically a control box (to make any changes in an object) with a space of only one thread at any given instant. So, multiple threads can be prevented from writing one object at the same time and protecting the object from getting corrupted. In it, wait() method tells a thread, if any other thread is already sitting in the monitor and if so, tells the calling thread to WAIT for the other thread to come out. Or technically, tells the calling thread to SLEEP until notified.
It stops any further execution of code in the calling thread, unlike a infinite loop, in which the execution continues, but no code after the loop is executed until the loop breaks.

In Java, how can other thread get chance to run after current thread is called on sleep() but still holds the lock?

In Java, a thread can go to sleep so that it won't hog the process and other thread can get chance to run. This is done by calling sleep().
However, different from calling wait(), the thread, after calling sleep(), will NOT release the lock it's been holding. Since this thread is still holding the lock, how can other thread get chance to run while not being able to get the unreleased lock?

They can't; other threads that need to acquire a lock held by a sleeping thread will block until they can get it. There's no way to back off like tryacquire on explicit Locks, so the threads are stuck.
Threads shouldn't sleep while holding a lock. If a thread isn't doing something useful it doesn't need to be holding a lock.
To go dormant and release a lock use the wait method. Sleep doesn't have any means to cut its sleep time short other than interruption (which should be used for cancellation), wait lets the thread be notified.

If you call Thread.sleep() while holding a lock or from inside a synchronized block/method, any other threads that reach that lock will wait until the first thread resumes and releases the lock.
However locks/synchronization are not global, any threads that don't reach the locks held by the sleeping thread can run without issue.

If other thread can't get the lock to run while this thread is going to sleep, then what's the purpose for this thread to go sleep at first place?
The only person who can answer that question is the person who wrote the code that runs in the thread.
Was that you?
As Nathan Hughes said, it practically never is a good idea for a thread to sleep() while holding a mutex lock. To take that idea a little further: It almost never is a good idea for a thread to do anything that takes more than a microsecond or so while holding a mutex lock. If you find yourself writing code that waits for something while keeping a lock locked, then that's a sign that you might need to re-think the architecture.
Also, there are not many good reasons for calling sleep() at all.
In Java, a thread can go to sleep so that it won't hog the process and other thread can get chance to run.
That's not really what sleep() is for. In most cases, when a thread doesn't need the CPU, it will block in a wait() call or in some xyz.await() call (where xyz is a queue or a semaphore or a latch or some other higher-level synchronization object).
The sleep() function is a low-level, primitive that your program can call in order to meet real-time requirements. But most programs with real-time requirements can make use of higher-level facilities such as java.util.concurrent.ScheduledThreadPoolExecutor
or javax.swing.Timer. If you start by writing your own sleep() calls, without first investigating the higher-level objects, then you may be re-inventing a wheel.

JAVA waking up threads in specific order

Let's say that i have 10 active threads and only 3 resources (of something)
while the first three threads got the resources i want all other thread that try to get the resource to wait but that the wake up or notify will be in f.i.f.o order i mean that the first thread that got the waiting will be the first to wake up.
thank you all.

I think this link explains it quite well: https://www.safaribooksonline.com/library/view/java-threads-second/1565924185/ch04s03.html
When using notify it is impossible to decide or determine in advance which thread will be allowed to execute. I see 2 solutions to this:
Use notifyAll() and let each thread check for itself whether whose turn it is (e.g. by using a synchronised FIFO queue)
Use the method described in the link: let each thread wait on a different object and use 1 thread that has as it's sole purpose to notify the correct object. This seems like the best solution to me.

Java generally doesn't decide these things however if you use a fair lock e.g.
Lock lock = new ReentrantLock(true);
then those threads will acquire the lock in the order they were attempted. This works by disregarding the order thread would be notified and ensuring a lock which is not taken unless the thread is next on the FIFO queue.

Calling notify() on an Object where no other threads are waiting on the same Object cost

What is the cost associated with calling notify() on an Object on which no other Objects have called wait() in Java?
The reason I am interested in this is because I have a worker thread that has a queue of Objects.
The thread loops continuously checking if it has any Objects in the queue that it needs to work with. If it loops and there is nothing in said queue the thread calls wait on on a separate Object.
When another thread adds an Object to the queue it calls notify on the Object that the worker thread would be waiting on regardless if the working thread is actually waiting.
Before anyone says anything, it is all synchronized correctly and won't throw any exceptions/errors.
My question is: is this setup slower then just having the worker thread just continue checking and never call wait() and what is the cost of calling notify() without any threads waiting on the Object?
Thanks for the help in advance :)

If you don't block worker thread, it'll be a busy-wait "spinloop" pattern, e.g. something like:
while (queue.isEmpty()) {
Thread.yield();
}
I've been reading about this model of conditional waiting today (in regards of my own problem :)) and found the following notes about when such model might show superior performance to ordinary wait() - notify() scheme:
... The main exceptions are those cases in which you somehow know that the condition must become true within some very short, boudned amount of time. In such cases, the time wasted spinning might be less than the time required to suspend and resume threads.
The book is "Concurrent Programming in Java: Design Principles and Patterns" by Doug Lea.

Using Object.wait(millisec) to simulate sleep

Here's a snippet of code that I saw in some code I'm maintaining.
Object lock = new Object();
synchronized( lock )
{
try
{
lock.wait( 50000 );
Thread.sleep( 3000 );
}
catch(Exception ex)
{
}
}
The developer wants to suspend the current thread for some amount of time and is using Object#wait as the mechanism. Obviously it is bad form to use the wait/notify protocol for this reason; however, is there any major difference between calling wait(millisec) and a Thread.sleep ?

Aside from having to get a monitor before waiting() there's no major difference anymore so long as no one external is going to be .notify()ing.
In ancient Java code you'd see people using wait() instead of Thread.sleep() because Thread.sleep() would freeze the whole application on systems without preemptive multitasking (I'm looking at you OS9). Technically wait() also let's you use nano-resolution waits, but in practice they're seldom that accurate.

Note that there is one key difference in using Object.wait() and Thread.sleep() inside a synchronization block: Thread.sleep() does not release the locked monitor, so no-one else can become the owner of the monitor.
In addition, Object.wait() does not guarantee that the delay indicated will be obeyed strictly. First of all, after the delay passes, the thread may still be waiting for another thread that has become the monitor owner in the meantime; and it may compete with other threads waiting to grab the monitor.
Second, the mythical spurious wake-up, as it is described in the Java 6 API javadoc:
A thread can also wake up without
being notified, interrupted, or timing
out, a so-called spurious wakeup.
Unlikely as it is, every piece of code using Object.wait() should take it into consideration.

You say it's "obviously" bad form to use wait/notify for this, but I don't see anything wrong with it. Admittedly following it up with a sleep call is very odd (and swallowing exceptions is bad), but I've definitely used Object.wait as a "breakable sleep" before now.
Imagine you've got a thread polling a resource every minute, but you want to be woken if something's happened (e.g. the resource location has changed, or the timer frequency has changed, or the program wants to quit in a graceful manner). Using wait/notify works extremely well for that - it's definitely cleaner than calling interrupt on the thread from elsewhere, as it doesn't matter if the notify occurs while you're actually processing instead of waiting.