Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

why wait and notify method is declared in Object class rather than Thread in Java

 
Roshi Kumar
Greenhorn
Posts: 21
Chrome Eclipse IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Thanks !
 
Chan Ag
Rancher
Posts: 1089
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Objects have behavior ( the methods ). These methods can be run by multiple threads concurrently unless the methods also enforce synchronization of some sort but the object itself does not need to be a Runnable or a Thread. Any thread's run method could invoke the said method from within its run method.

Any object can have synchronized methods/block that need to notify waiting threads. Since all objects needs to be able to have methods/blocks that can wait, notify, and notifyAll, these methods are defined in Object class.

Chan.

 
Henry Wong
author
Marshal
Pie
Posts: 20902
76
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Likes 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Interestingly, neither option is entirely correct. Let me explain...

Between the two options, having wait() and notify() with the Thread object only is obviously incorrect. The wait/notify mechanism is related to the synchronization mechanism -- and since synchronization can be done with any object, you should be able to do notifications with any object.

On the other hand, having wait/notify with the Object class isn't entirely correct either. There isn't a one to one relationship between a mutex (synchronization mechanism) and its condition variable (wait/notify mechanism). For example, I can lock a data structure, but can have two conditions -- such as data structure empty and data structure full -- to do notifications on. This means that it should be possible to have more than one condition variable for the same lock.


Anyway, the correct solution is to implement a locking / condition variable mechanism -- which was done with Java 5. See the ReentrantLock and the Condition class for a complete implementation of mutex locks and condition variables..

Henry
 
Chan Ag
Rancher
Posts: 1089
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, Henry.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic