Re: notify / notifyAll misunderstanding

From: VisionSet (spam_at_ntlworld.com)
Date: 07/13/04 

Date: Tue, 13 Jul 2004 18:01:09 GMT

"Filip Larsen" <filip.larsen@nospam.dk> wrote in message
news:cd13nt$1928$1@news.cybercity.dk...
> Mike wrote
>
> > I have a record locking system that I have condensed to the simple
> example
> > below.
>
> > With notifyAll() I always get:
> >
> > locked 5
> > locked 6
> > unlocked 5
> > locked 5
>
> This looks like the correct behaviour because you have two threads
> trying to lock 5, and they both get turns.

No, I don't see it that way.
The 1st 5 thread will lock because 5 is not locked.
But when that is unlocked notifyAll will wake all threads but ONLY ONE will
aquire the lock on the Set object, this is arbitrary and sinece there are 7
lots of threads waiting to lock 6 versus 1 thread trying to lock 5 then it
is likely the 6 thread will win. Since notifyAll is only called once in this
example I don't see that the waiting threads get another chance to aquire
the lock.

>
> > notify() on the other hand works as expected ie:
> >
> > locked 5
> > locked 6
> > unlocked 5
>
> This does not look correct because when you use notify only one
> (arbitrary choosen) thread that wait on the lock gets notified and the
> second "lock 5" thread will therefore (probably) never be notified to
> discover that 5 indeed is available for locking again.

Yes I understand this, but for the same reason this should be the case for
notifyAll(), since although all waiting threads are woken (I know they
weren't sleeping) ONLY ONE will run and which one is arbitrary.

>
> As a rule of thumb you should only use notify when the condition you
> wait for is implied by the lock itself. If the wait is inside a while
> loop you probably need to use notifyAll. In your case you could for
> instance, with some modification to the code of course, wait for a
> separate object for each integer, in which case you *can* use notify
> because all threads that wait on the "5-object" is then in fact trying
> to lock 5.

Thanks that is useful, I'll give it some thought.
But my main reason for the post is to understand the notifyAll quandry,
which I still don't :-( 

--
Mike W

Relevant Pages

  • notify / notifyAll misunderstanding
    ... notify wakes up a waiting thread that then attempts to ... waiting threads and ONLY ONE gains the lock, the others go back to waiting. ... When unlockis called a record is removed from the set and notifyAll() is ... So 8 waiting threads are then all notified and 1 arbitraily gets the lock. ...
    (comp.lang.java.programmer)
  • Re: Multithreading - Problem with notifyAll() and wait()
    ... NotifyAll() and waitstatements (producer notifies and consumer ... You could replace lock in the code below with some other common object to synchronize on and save the needless creation of another object called lock. ...
    (comp.lang.java.programmer)
  • Re: notify / notifyAll misunderstanding
    ... I.e. if a lock for a particular record is ... > you want one of the waiting threads to reliably get the lock? ... Yes, I was just using it to understand the notifyAll(), which I now do ... Mike W ...
    (comp.lang.java.programmer)
  • RE: lock cells based on interior color
    ... corresponding row to lock) and the second column is Q7:Q37 (if its value ... "Mike H" wrote: ... format and lock the cells based on that. ...
    (microsoft.public.excel.misc)
  • Re: Locks: Sicheres =?UTF-8?B?aG9jaHrDpGhsZW4gaW4gbXVsdGl1c2VydW0=?= =?UTF-8?B?Z2VidW5n?=
    ... Hallo MIke, ... update User1 set counter=+1 ... denselben wert zunächst auslesen aus der table, und dann beide hintereinander auf denselben wert updaten (da ja ... Bei obiger Syntax wird bereits zu Beginn ein "U"pdate Lock gesetzt, ...
    (microsoft.public.de.sqlserver)