4

For the following code notifyAll() will hold the lock until done, even when the timeout has reached, this block doesn't hold the lock and has to wait for the notifyAll() block to be finished. Then what's the meaning of the timeout in wait(timeout) if after the timeout is done we still have to wait for the lock? Also - how to change the code so that the timeout will have meaning?

// one thread
synchronized (lock) {
  lock.wait(timeout);
}

// second thread
synchronized (lock) {
  // do some processing actions.......
  lock.notifyAll();
}
Aya1
  • 49
  • 5
  • possible duplicate of [How to differentiate when wait(long timeout) exit for notify or timeout?](http://stackoverflow.com/questions/3397722/how-to-differentiate-when-waitlong-timeout-exit-for-notify-or-timeout) – Joe Apr 28 '15 at 11:36
  • Well, what if you never lock and notify. – Mordechai Apr 28 '15 at 11:39
  • Re, _...if we still have to wait for the lock..._: No thread should ever have to wait for any significant amount of time to acquire a lock. You can write a program in which threads _do_ wait for locks, but that's bad design. In a well-designed program, locks are only used _briefly_---just long enough to insure that some group of variables is updated as an atomic unit---and any time a thread has to truly _wait_ for something, it `wait()`s. – Solomon Slow Apr 28 '15 at 13:26

3 Answers3

3

You are indeed correct that the waiting thread actually goes through 2 types of wait: wait for an explicit 'notify/notifyAll', and then wait for an opportunity to get the synchronization lock.

The hope is, that most other threads that use 'synchronized' will only hold the synchronization lock for a brief time. That's a very strongly recommended practice. A private case of it is the thread that calls 'notifyAll' - this is a very short action, and the synchronization block is existed very quickly.

To summarize: the thread might be stuck on 'lock.wait' for a long time (e.g. "waiting for a customer to arrive" - this could take hours, and you might consider a timeout after which you despair of business). However, once the notification arrives and it competes on 'synchronized' - this competition should be brief, so brief that it's not worth it to consider timeout. However, this relies on the good will of your fellow programmers, that should only use synchronized for short blocks (e.g. avoiding a race condition in that fraction of a second when you're updating a variable). It's a matter of good practice.

Pelit Mamani
  • 2,321
  • 2
  • 13
  • 11
  • So @Pelit-Mamani, do you agree that there's no meaning to the wait timeout? – Aya1 Apr 28 '15 at 12:13
  • 1
    @Aya1, Pelit-Mamani said the exact opposite of that. In a well-designed program, the time that any thread spends waiting for a lock will be nearly zero. In a well designed program, a producer will do some work, and then it will _very briefly_ lock a lock, put the work result in a queue, notify the consumer, and unlock the lock. The producer will _not_ hold the lock while it is doing the work. If a consumer times-out waiting for the work, it is highly likely that the lock will free at that moment, and the `wait(t)` call will promptly return. That is, in a _well designed program._ – Solomon Slow Apr 28 '15 at 13:36
  • "james large" has explained it nicely. Correlating his producer/consumer with my example of "waiting for customers": assume you design thread#1 to wait for customers to arrive (lock.wait), and thread#2 is responsible for detecting such customers and notify. It's reasonable to limit to wait to (say) an hour, if no customers arrive by then - move on to some desperate logic (close shop?). That's reasonable. You seem to worry about the further need to wait on the 'synchronized' block, but this is totally negligible, it's a fraction of a second and hardly felt.... – Pelit Mamani Apr 28 '15 at 19:32
0

The wait's timeout has a good meaning. Just read and JavaDoc and think about it. Not sure why you think it has no meaning here, I guess you just got confused.

Causes the current thread to wait until either another thread invokes the notify() method or the notifyAll() method for this object, or a specified amount of time has elapsed.

The current thread must own this object's monitor.

Object.wait(long)

Community
  • 1
  • 1
peter.petrov
  • 38,363
  • 16
  • 94
  • 159
  • Lets say the wait timeout is 1 sec and the block with the notifyAll() takes 3 seconds to run. What happens is that the first thread holds the lock, and the wait() releases it, then the second thread get a hold of the lock. The timeout reaches but the first thread doesn't hold the lock and has to wait for the second thread to be done. Therefor the total wait will be 3 seconds instead on one. In this scenario there's no meaning to the timeout. – Aya1 Apr 28 '15 at 11:50
  • see my answer above. you say "has to wait for the second thread to be done" but it will be done in a fraction of a second! Then your first thread can get back info the synchronized block – Pelit Mamani Apr 28 '15 at 12:03
0

There are situations, where lock.wait() waits for a resource, which may never be available (lock.notify() is never called). For example, responce from the remote computer will never be recieved if it is crashed(or network is crashed).

One choice in these situation is to wait forever, allowing user to interrupt waiting by hands.

Another choice is to use lock.wait(timeout) to wait for a limited amount of time, assuming resource as inaccessible after that amount is expired. In that case(after timeout is expired) program can choose another way to complete task. Or program can simply exit and allow other programs to do their work.

Without taking spurious wakeups into account, usage is simple:

if(!condition)
{
    lock.wait(timeout);
    if(!condition)
    {
        //timeout expired while waiting
    }
}
// 'condition' is true now
Tsyvarev
  • 60,011
  • 17
  • 110
  • 153