[Java - Synchronization] Wait() and Notify()

1) Explanation

wait() tells the calling thread to wait (possibly forever) until some other thread tells it to resume using the method, notify( ).
notify method is used, with wait(), to wake up threads that are waiting for an access to this object’s monitor. There are two ways to notify; notify() and notifyAll().

Notify() will wake up a randomly selected thread waiting on this object’s monitor.

Since notify() wakes up a single random thread it can be used to implement mutually exclusive locking where threads are doing similar tasks, but in most cases, it would be more viable to implement notifyAll().

NotifyAll() wakes all threads that are waiting on this object’s monitor.

The awakened threads will complete in the usual manner – like any other thread.

* There is a tricky part about notify methods, and that is, it only releases the lock after the methods following the notify method is completed as well (usually until it reaches the wait() statement). This will be explained more later.

1.1) More advanced details:

notify(): If the objects container house has multiple threads in waiting state then calling notify() on the this object given chance to one the thread to proceed. But after coming out of the waiting state the thread still has to contest for the object monitor and if it succeeds in getting the monitor it continue its execution otherwise thread will come back to waiting state. So notify() also has to be called from the synchronized block. If the notify() is not called from synchronized context then it throws IllegalMonitorStateException.

notifyAll(): Calling notifyAll() on the Object makes sure all the threads in Object container house are awakened but once awakened they have to compete with each other or any other thread wants to acquire the object monitor. Which ever thread succeeds continue its executions others have to go back to waiting state and settle in object container house. As notify(), notifyAll() should also be called in synchronized context.

2) Example Code




2.1) Explanation

First, we create a LinkedList that is shared amongst our consumerThread and producerThread. 
When both these threads start, (if consumerThread starts first) consumerThread will realize that it is empty and execute wait(), which frees up the lock for producerThread to access the synchronized block.
producerThread will fill up the LinkedList until it's full and execute wait(), which frees up the lock for consumerThread to consume.
And this goes on forever.

2.2) Expected Output


Que is Empty
Producing Value 2
Producing Value 52
Producing Value 87
Producing Value 39
Queue is Full
removing Element 2
removing Element 52
removing Element 87
removing Element 39
Que is Empty
....

2.3) If notify method releases the lock for the other thread, shouldn't the producer and consumer be constantly releasing the lock (rather than wait till the upper and lower limits are hit)?

The notify method truly releases the lock when it has completed its operations. Because we are putting the notify method in the while loop, it keeps looping until it hits the wait() method.
If we didn't put it in a while loop, then yes, the lock will be released after the code after notify method are completed.

2.4) Then, why can't we just use wait() if it has to reach wait() to truly release the lock?

Even though wait() does make the thread let go of the lock, it does not wake up the other thread to compete (or get) the lock.

2.5) Why is wait() in a while-loop?

Because notify() and notifyAll() randomly wakes up threads that are waiting on this object’s monitor, it’s not always important that the condition is met. Sometimes it can happen that the thread is woken up, but the condition isn’t actually satisfied yet.

We can also define a check to save us from spurious wakeups – where a thread can wake up from waiting without ever having received a notification.

Shouldn't the lock be released after the notify method?

3) Conclusion

Note that wait(), notify() and notifyAll() are low-level APIs - more traditional methods. They work well, but higher-level mechanism are often simpler and better – such as Java’s native Lock and Condition interfaces (available in java.util.concurrent.locks package).

Comments

Post a Comment

Popular posts from this blog

[Redis] Redis Cluster vs Redis Sentinel

1) In-Depth Guides to Redis Cluster and Sentinel For more in-depth explanation for Redis Cluster or Redis Sentinel, please read my other posts: Sentinel:  https://notafraidofwong.blogspot.com/2019/05/redis-redis-sentinel.html Cluster:  https://notafraidofwong.blogspot.com/2019/05/redis-redis-cluster.html 2) Deciding between Redis Sentinel and Redis Cluster Similarities : Both solutions provide high availability for your system. 2.1) Redis Cluster 2.1.1) Pros Shards data across multiple nodes Has replication support Has built-in failover of master 2.1.2) Cons Not every library supports it May not be as robust (yet) as Standalone Redis or Sentinel Setup and maintenance is more complicated 2.2) Redis Sentinel 2.2.1) Pros Automatically selects new master in case of failure Easy to setup, (seems) easy to maintain 2.2.2) Cons No data sharding; master might be overutilized. Another distributed system to maintain. 3) So how do I dec...
Read more

[Java - Synchronization] Semaphores and Mutex

Image
1) Semaphore Basically, a counter that limits the number of concurrent threads accessing a specific resource. In general, to use a semaphore, the thread that wants access to the shared resource tries to acquire a permit. If the semaphore’s count is greater than zero, then the thread acquires a permit, which causes the semaphore’s count to be decremented. Otherwise, the thread will be blocked until a permit can be acquired. When the thread no longer needs an access to the shared resource, it releases the permit, which causes the semaphore’s count to be incremented. If there is another thread waiting for a permit, then that thread will acquire a permit at that time. Java provide Semaphore class in java.util.concurrent package that implements this mechanism, so you don’t have to implement your own semaphores. 1.1) Constructor Semaphore(int permits): creates Semaphore with given number of permits and nonfair fairness setting. Semaphore(int permits, boolean fair...
Read more

[Unit Testing] Test Doubles (Stubs, Mocks....etc)

Image
In unit testing, isolation is key. The goal of unit testing is to test individual components, and not an entire system . The class/object/function you are testing is System Under Test (SUT) , and the other components of the system are Collaborators or Dependencies. Test Double  is a generic term for any kind of 'pretend' object used in place of a real object for testing purposes.  There are several types of Testing Doubles. We will start with: Fake Stub Mock Command Queries Mocks vs Stubs And then: Dummy Spies Spies vs Mocks I) Basic Testing Doubles a) Fake Fake are objects that have working implementations, but not same as production one. Usually they take some shortcut and have simplified version of production code. Note that Fake is a generic term - that can point to anything; usually mock and stubs. An example of this is an in-memory implementation of a database. This fake implementation will not access the actual database, but will ...
Read more