Win a copy of Head First Android this week in the Android forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Rob Spoor
  • Devaka Cooray
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Tim Holloway
Bartenders:
  • Jj Roberts
  • Al Hobbs
  • Piet Souris

wait/notify/notifyAll and synchronized context

 
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
KB book says (page 719) that wait(), notify() and notityAll() must be called from within a synchronized method because they can't be invoked on an object if the thread hasn't the lock on that object (guaranteed using synchronized keyword).

Could someone explain the reason? Or this is a rule I have to "just memorize"?

Thanks
 
author
Posts: 23909
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Could someone explain the reason? Or this is a rule I have to "just memorize"?



Simple reason -- everyone else does it. If you look at condition variables for the POSIX, Solaris, Windows, etc., threading systems, every one of them requires that a specific mutex be held for the condition variable -- and it is the condition variable that releases and reacquires the mutex.

More complex reason -- it can't be done without integrating the mutex with the condition variable. (or in Java speak, without integrating the synchronization locks with the wait/notify mechanism). If you don't use synchronization, you'll run into race condition that can't be solved (which notification might be lost). If you do use synchronization, but have the two mechisms separated (ie. wait and notify doesn't release and reacquire the lock). you'll still have race conditions that can't be solved (and again, notifications may be lost).

So... you need the wait / notify mechanism to release and reacquire the lock -- hence, the wait and notify methods must be called from a synchronized context.

Henry
 
Paolo Dina
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's clear, thanks!
 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Dina and Wong.......That is my Doubt too..........
 
reply
    Bookmark Topic Watch Topic
  • New Topic