• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Is notifyAll good enough?

 
Yuan Ye
Ranch Hand
Posts: 172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
HI. All
Still another question about the lock/unlock. I used the approach of Max's book, a static vector as the holder of all lockers. My question is would the notifyAll in unlock method be good enough?
Consider this:
thread1 wait on record1,
thread2 wait on record2,
thread3 gain lock of record1;
After thread3 unlock record1, it calls notifyAll on thread1 and thread2.
It is possible that thread2 wake up, and it found record2 is still locked, so thread2 back to wait. But then how about thread1, does it still get a chance to wake up? If not then when it will be waken, waiting next notifyAll and gain luck? I am a little confused. need light.
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Peter,
After thread3 unlock record1, it calls notifyAll on thread1 and thread2.
It is possible that thread2 wake up, and it found record2 is still locked, so thread2 back to wait. But then how about thread1, does it still get a chance to wake up? If not then when it will be waken, waiting next notifyAll and gain luck? I am a little confused. need light.

All waiting threads will be awoken and get the chance of testing their waiting condition. It's OK IMO.
Best,
Phil.
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Peter,
My question is would the notifyAll in unlock method be good enough

YES.
Best,
Vlad
 
Eduardo Rodrigues
Ranch Hand
Posts: 199
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is everything ok with your code...
Bye
 
Akash Singh
Ranch Hand
Posts: 80
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JVM thread scheduler is also dependent on operating system
for thread management. If OS finds that some thread is
not getting chance to exceute in preemptive scheduling,
it may increase the priority of the thread to give chance to
exceute this waiting thread. In Time sharing every waiting thread
will get chance to execute for a time interval.
I think Unix and Windows have preemptive thread scheduling.
So, notifyAll() will work for you. However, if instead of waiting, if
your thread is sleeping at time of notifyAll(), then this sleeping
thread will miss notifyAll() call.

Correct me gurus, if am wrong.

Regards,
Akash
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12007
215
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Akash,
If you are talking about a thread which calls sleep() before calling wait(), then you are correct: the thread that is currently processing the call to sleep() will not be woken by the call to notify() or notifyAll().
But if you are talking about the thread state, then scheduling makes no difference - all threads which called wait() will be woken by the thread calling notifyAll().
Regards, Andrew
 
Akash Singh
Ranch Hand
Posts: 80
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

If you are talking about a thread which calls sleep() before calling wait(), then you are correct: the thread that is currently processing the call to sleep() will not be woken by the call to notify() or notifyAll().
Yes.

But if you are talking about the thread state, then scheduling makes no difference - all threads which called wait() will be woken by the thread calling notifyAll().
Yes. but only of one those waiting thread would get change to acquire lock and proceed; others would again go in wait, isn't it ?
Regards,
Akash
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12007
215
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Akash,
Originally posted by Akash Singh:
Yes. but only of one those waiting thread would get change to acquire lock and proceed; others would again go in wait, isn't it ?

No - all of them will be woken up and all will get the chance to acquire the lock.
Only one of them will aquire the mutex that you are synchronized on, but the others will not automatically go back into waiting - they will all be awake and eagerly trying to grab the mutex. Each one in turn should check if the condition it is waiting on has changed. If the condition has changed, it should do whatever work it requires, and release the mutex (thereby allowing another thread to grab it - no call to notify() or notifyAll() required). If the condition has not changed then that thread should call wait() which will release the mutex (thereby allowing another thread to grab it - no call to notify() or notifyAll() required).
Regards, Andrew
 
Akash Singh
Ranch Hand
Posts: 80
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Andrew. Thanks for correcting me, and explaining in detail. I believe, this will help Peter too.

Regards,
Akash
 
Yuan Ye
Ranch Hand
Posts: 172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks all for the explain. It clears a lot and I am quite happy now.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic