Are Java wait (), notify () significantly different from locks?

Question

Out of curiosity, when Java implements the wait () and notify () methods, do they really use locks? i.e. wait () gets mutex, notify () frees the mutex, notifyAll () frees all the mutexes (in the same object, of course)?

Besides being less cumbersome than using locks, are there other benefits to using wait () and notify ()?

[EDIT] I realized what I was embarrassed about after Brian noticed:

wait is not blocked, it releases the lock and passes it to someone else who is waiting for a synchronized statement for the mutex, and then waits for someone else who has the lock and call notifications to send it, which transfers the lock back to the original topic called wait. I think you are embarrassed. - Brian 17 minutes ago

Answer 1

wait() and notify() do not monitor anything. as stated in javadoc for these methods, the caller must receive a monitor before the call. in fact, wait() actually frees up the monitor that the caller has received (although, I assume that technically the wait does the observation (repeat) until the final return).

Answer 2

Other questions have focused on what the language says, wait and notify - but that doesn't look like what your question is about ... you are talking about mutexes, which are an implementation detail and therefore the JVM is specific.

So, we need to choose a JVM - let us choose openjdk (the source is available here ). The bit of code that (ultimately) handles all this is in hotspot/src/share/vm/runtime/objectMonitor.cpp .

It supports two data structures - a wait set and a record set. Waiting lines are added to the waiting set and parked, while threads trying to take the monitor are added to the record set and then parked. On notify stream is taken from the wait set and added to the record set. When a thread releases a lock, it discards the thread from the recordset, if any. Note that these sets are actually implemented as queues (linked lists), so they are processed based on FIFO.

Therefore, in this particular case, the implementation considers the wait on the object monitor and tries to make the object monitor the same way.

But this is just one implementation of one JVM (although others probably do something similar), so we cannot rely on it. So, I suppose, the question is, why do you want to know? If this is just curiosity then check out the openjdk code, this is fun. If you plan to use this information in your code ... do not do this.

UPDATE

I understand that saying “park” doesn’t tell us very much. The code that stores the stream is platform specific (and implemented in an object called PlatformEvent , which ParkEvent extends). In the openjdk version that I am looking at the linux park code can be found in hotspot/src/os/linux/vm/os_linux.cpp and this calls pthread_mutex_lock(_mutex) ... so in answer to your question yes a call may be required mutex on my car. Please note that there are many things that can happen above this, which may prevent us from reaching this point.

Answer 3

wait releases the lock that you already have in order to re-get it at some point in the future, after someone else calls notify . This is in addition to the locking mechanisms provided by synchronized . Basically you use synchronized to get a lock, then you use wait , notify and notifyAll to control how these locks are released and locked.

Answer 4

wait() , notify() always work together with synchronization, so there may be a comparison between Locks and synchronization. There is a big difference between locks such as RentrantLock, ReadWriteLock, and Synchronization [block, methods].

• Locks do not use synchronization inside, and wait() , notify() will need synchronization.

• You use Lock along with java.util.concurrent.locks.Condition, which effectively provides conditional locking, which is quite tedious for synchronization implementation.

• You do not have the tryLock option with synchronization, you either block or wait. But with the Lock interface you have a choice.

Answer 5

Out of curiosity, when Java implements the wait () and notify () methods, do they really use locks? i.e. wait () gets mutex, notify () frees the mutex, notifyAll () frees all the mutex?

Sorry, none of this happened. :)

• This is the synchronized that monitor gets. those. This is a form of blocking. NB: using java.util.concurrent.locks.Lock does something similar.
• wait() causes the current thread to wait until another thread calls the notify() method or the notifyAll() method for this object, or the elapsed specified amount of time. There is nothing to do with locking, but can only call this method when the current thread of the current thread already belongs to this monitor object (in the synchronized block / method)
• notify() wakes up one thread waiting for this object monitor. Again, it has nothing to do with locking, but can only call this method when the current thread of the current thread already belongs to this monitor object (in the synchronized block / method)