Condition against pending notification mechanism

Question

What is the advantage of using the Condition interface / implementation over the regular wait notification mechanism? Here I quote the comments written by Doug Lee:

The condition takes into account object monitoring methods (wait, notify, and notifyAll) in different objects to give the effect of having multiple wait sets for each object, combining them using arbitrary lock implementations. If locking replaces the use of synchronized methods and operators, the condition replaces the use of object monitoring methods.

I see that this is a more object-oriented way to implement a wait / notification mechanism. But is there an advantage over the first?

Answer 1

There are many benefits. , as mentioned above about the Condition Interface , some of them are as follows:

The status interface comes with two additional methods , which are:

1) boolean awaitUntil (Date deadline) throws InterruptedException: Causes the current thread to wait until it is signaled or interrupted, or the specified deadline has expired.

2) awaitUninterruptibly (): Causes the current thread to wait until it is signaled.

If the current state of thread interruption is set when it enters this method, or it is interrupted while waiting, it will continue to wait until it is signaled. When he finally returns from this method, his aborted status will still be set.

The above two methods are not present in the standard monitor, which is in the object class, in some situations we want to set the deadline for the stream that we expect, then we can do this using the Condition interface.

In some situations, we don’t want to interrupt the stream and we want the current stream to wait until it is signaled, then we can wait. The continuous method is present in the conditions interface.

Additional Information Conditions Java Interface Documentation:

http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/locks/Condition.html#awaitUntil%28java.util.Date%29

Answer 2

The biggest problem is that wait / notify is error prone for new developers. The main problem is that you do not know how to handle them correctly, this can lead to an error.

• if you call notify () before wait (), it is lost.
• Sometimes it is not clear whether notifications () and wait () are called on the same object.
• There is nothing pending / notification that requires a state change, but in most cases this is required.
• wait () may return false

The condition completes this functionality in the selected component, however, it behaves almost the same.

The question is that wait / nofity sent the minutes before and many, many others. Search [java] + wait + notify

Answer 3

When you use Condition: await()/signal() , you can distinguish which object or group of objects / streams receives a particular signal. Here is a brief example where some threads, producers, will receive an isEmpty signal, while consumers will receive an isFull signal:

 private volatile boolean usedData = true;//mutex for data private final Lock lock = new ReentrantLock(); private final Condition isEmpty = lock.newCondition(); private final Condition isFull = lock.newCondition(); public void setData(int data) throws InterruptedException { lock.lock(); try { while(!usedData) {//wait for data to be used isEmpty.await(); } this.data = data; isFull.signal();//broadcast that the data is now full. usedData = false;//tell others I created new data. }finally { lock.unlock();//interrupt or not, release lock } } public void getData() throws InterruptedException{ lock.lock(); try { while(usedData) {//usedData is lingo for empty isFull.await(); } isEmpty.signal();//tell the producers to produce some more. usedData = true;//tell others I have used the data. }finally {//interrupted or not, always release lock lock.unlock(); } } 

Answer 4

To specifically indicate why having multiple waitsets is an advantage:

With waiting / notification, if there are different things that are waiting for threads (a common example is a lock of a fixed size, with some threads putting things in a queue and blocking when the queue is full, and other threads taken from the queue and blocking when the queue is empty) , then if you use a notification, forcing the scheduler to select one thread from the waiting set for notification, you may have angular cases when the selected thread is not interested in receiving notification of a specific situation. For example, the queue will notify when something is added to the queue, but if the selected stream is a producer and the queue is full, then it cannot act on this notification, which you prefer to use for the consumer. With internal locking, you should use notifyAll to make sure that notifications are not lost.

But notifyAll crashes on every call, where each thread wakes up and protects the lock, but only one can make progress. The rest of the threads all collide, fighting for a lock, until, one at a time, they can get a lock and, most likely, return to waiting. It generates a lot of disagreement, which does not bring much benefit, it would be preferable to be able to use the notification and know that only one stream is notified, where the notification refers to this stream.

There are separate waiting conditions - this is a big improvement. A queue can cause a signal under the condition and know that it will awaken only one thread, where this thread specifically expects a condition.

The doc for Condition API has sample code that shows the use of several conditions for a limited buffer, it says:

We would like to continue waiting to set streams and receive streams in separate waiting sets, so that we can use optimization only to notify one stream at a time when elements or spaces become available in the buffer.

Answer 5

@AfterWorkGuinness

If you do not set usedData = true / false before signaling

After the signal code reaches the end of the blocking block and release it, the order does not matter.