calling wait outside of loop

Discussion in 'Java' started by puzzlecracker, May 7, 2006.

  1. The argument is that calling wait prior to loop me cause a thread never
    to be aweken (given that notify[all] has been called prior)

    How does waiting in the loop prevent that:

    while(a condition){
    obj.wait();

    }
    and notify has been called prior to wait, indefinite sleep is
    guaranteed.

    what is the argument for calleding after the loop.

    thanks
     
    puzzlecracker, May 7, 2006
    #1
    1. Advertising

  2. puzzlecracker wrote:
    > The argument is that calling wait prior to loop me cause a thread never
    > to be aweken (given that notify[all] has been called prior)
    >
    > How does waiting in the loop prevent that:
    >
    > while(a condition){
    > obj.wait();
    >
    > }
    > and notify has been called prior to wait, indefinite sleep is
    > guaranteed.
    >
    > what is the argument for calleding after the loop.


    Are you asking why the following code is not used?

    if (...condition...) { // Wrong...
    lock.wait();
    }

    Firstly there is the problem of spurious wakeups. wait can exit at any
    time, without reason. Therefore the loop is always necessary.

    Even if there were no spurious wakeups, it's still usually wrong.
    Typically you may have multiple threads waiting, only one of which can
    proceed. Each thread will need to check the notify is for them. For
    instance, two threads are waiting to take an element off a blocking
    queue, if notifyAll is used both will wake but only one should grab the
    new element.

    Tom Hawtin
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
     
    Thomas Hawtin, May 7, 2006
    #2
    1. Advertising

  3. puzzlecracker

    hiwa Guest

    puzzlecracker ã®ãƒ¡ãƒƒã‚»ãƒ¼ã‚¸:

    > The argument is that calling wait prior to loop me cause a thread never
    > to be aweken (given that notify[all] has been called prior)
    >
    > How does waiting in the loop prevent that:
    >
    > while(a condition){
    > obj.wait();
    >
    > }
    > and notify has been called prior to wait, indefinite sleep is
    > guaranteed.
    >
    > what is the argument for calleding after the loop.
    >
    > thanks

    I don't understand your English.
     
    hiwa, May 7, 2006
    #3
  4. puzzlecracker

    Mitch Guest

    puzzlecracker wrote:
    > The argument is that calling wait prior to loop me cause a thread never
    > to be aweken (given that notify[all] has been called prior)
    >
    > How does waiting in the loop prevent that:
    >
    > while(a condition){
    > obj.wait();
    >
    > }
    > and notify has been called prior to wait, indefinite sleep is
    > guaranteed.
    >
    > what is the argument for calleding after the loop.
    >
    > thanks
    >


    Do you mean that you are calling notify sometimes before the obj.wait()
    and its loop are called? If this is the case, when you call notify you
    could set a flag boolean notifyCalled = true and in the while loop you
    could write while(a condition && !notifyCalled)

    But as mentioned before, your English means it is difficult to guess at
    what you mean.
     
    Mitch, May 8, 2006
    #4
  5. puzzlecracker

    Mitch Guest

    Mitch wrote:
    > puzzlecracker wrote:
    >> The argument is that calling wait prior to loop me cause a thread never
    >> to be aweken (given that notify[all] has been called prior)
    >>
    >> How does waiting in the loop prevent that:
    >>
    >> while(a condition){
    >> obj.wait();
    >>
    >> }
    >> and notify has been called prior to wait, indefinite sleep is
    >> guaranteed.
    >>
    >> what is the argument for calleding after the loop.
    >> thanks
    >>

    >
    > Do you mean that you are calling notify sometimes before the obj.wait()
    > and its loop are called? If this is the case, when you call notify you
    > could set a flag boolean notifyCalled = true and in the while loop you
    > could write while(a condition && !notifyCalled)
    >
    > But as mentioned before, your English means it is difficult to guess at
    > what you mean.


    Actually you would probably write

    if(!notifyCalled){
    while(a condition){
    obj.wait();
    }
    }

    I wrote the previous in a general sense, only to realise that after
    posting, it wouldn't actually work.
     
    Mitch, May 8, 2006
    #5
  6. On Mon, 08 May 2006 13:16:37 +0100, Mitch wrote:
    > Actually you would probably write
    >
    > if(!notifyCalled){
    > while(a condition){
    > obj.wait();
    > }
    > }


    No. There is already a "real" reason for the notification ("a
    condition"), and it should be set by the notifying thread before
    notify() is called, within the synchronized block:

    synchronized (someObject) {
    setCondition(true);
    someObject.notify();
    }

    The waiting thread *must* test for that condition before calling
    wait() in every case. This is sufficient to avoid problems caused by
    calling notify() prior to wait():

    synchronized (someObject) {
    while (!getCondition()) { /* until the condition becomes true */
    someObject.wait();
    }
    }

    Adding an additional, artifical condition (notifyCalled) gains you
    nothing and in fact only distracts from the real condition that is
    being communicated between the threads. Understand too the distinction
    between a condition stated in terms of the problem domain (e.g. "data
    is ready"), and in terms of the implementation ("notify was called").
    The latter of these indicates poor design IMO.

    The loop is necessary in the case of spurious interrupts, but it also
    lets multiple waiting threads contend on a single lock when
    notifyAll() is used (and in this case, the condition should likely be
    "cleared" by the first waiting thread that discovers the condition).

    /gordon

    --
    [ do not email me copies of your followups ]
    g o r d o n + n e w s @ b a l d e r 1 3 . s e
     
    Gordon Beaton, May 8, 2006
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. -
    Replies:
    12
    Views:
    702
    Remon van Vliet
    Jun 15, 2005
  2. Huey

    How to make "fork/wait" to WAIT longer?

    Huey, Mar 1, 2004, in forum: C Programming
    Replies:
    1
    Views:
    1,980
    -berlin.de
    Mar 1, 2004
  3. Ernst Tanaka

    dde "wait loop"

    Ernst Tanaka, Jan 8, 2008, in forum: Ruby
    Replies:
    5
    Views:
    135
    Ernst Tanaka
    Jan 18, 2008
  4. Krzysztof Poc

    outside type, outside function

    Krzysztof Poc, Feb 3, 2012, in forum: C++
    Replies:
    1
    Views:
    300
    Victor Bazarov
    Feb 7, 2012
  5. Isaac Won
    Replies:
    9
    Views:
    398
    Ulrich Eckhardt
    Mar 4, 2013
Loading...

Share This Page