• 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Knute Snortum
  • Paul Clapham
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Frits Walraven
Bartenders:
  • Ganesh Patekar
  • Tim Holloway
  • salvin francis

Why in java.lang.Object?  RSS feed

 
Ranch Hand
Posts: 3389
Mac MySQL Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi ppl,
I have a question which was asked in an interview.

java.lang.Object [superclass of any object] does have 3 methods related to threads, namely
(a) wait()
(b) notify()
(c) notifyAll().

The question was,"Why these threads related methods are present in Object class rather than in java.lang.Thread class?".

Can you please give a suitable answer?

Thanks,
Raghavan alias Saravanan M.
 
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
because the language designers chose to put them there...

You notify something waiting on a thread, not the thread itself.
Same with waiting, you wait for some object to become free, not on a thread to release a lock per se.

Etc. etc.

second guessing language designers is a waste of time, unless you're a language designer of at least equal experience yourself.
 
Ranch Hand
Posts: 3271
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Think for a moment about what those methods do. Let's just look at one of them - wait(). This method causes the current thread to stop processing until some other thread invokes notify() or notifyAll() and it can resume processing. So, this method really only makes sense in a multi-threaded environment.

Now, think about how we can create new threads. You can extend the Thread class or you can create a class that implements Runnable. And let's not forget that your entry method (main) is going to be executed by a thread. So you might want to invoke wait() from a class that extends Thread, from a class that implements Runnable, or from a class that does neither. So where can the methods wait, notify, and notifyAll go such that all three of these cases will have access to them? java.lang.Object.
[ April 26, 2006: Message edited by: Corey McGlone ]
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Some teams have a "build token" like a toy monkey that you have to have in hand before you can check in code. If you want to check in, you go get the token off its hook on the wall. If it's not there, you wait until the token is back on its hook. You don't know who has it so you can't wait on them. You just watch the hook.

Same with these methods. You use some object as the hook, and the thread monitor as the token. You don't know what thread has the monitor so you can't call a method on that thread to wait. And calling a method on your own thread wouldn't help because it doesn't have the monitor. You just wait until the other thread gives up the monitor and puts the token back on the hook.

 
Raghavan Muthu
Ranch Hand
Posts: 3389
Mac MySQL Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks a lot for Joreon, Corey and James!
The justification/reason was excellent.

Thanks,
Raghavan alias Saravanan M.
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To clarify a bit what Cory said: In Java you're effectively ALWAYS working multithreaded (even if you may not notice).
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Last night I was trying to see how far I could stretch this build token fable ...

When somebody puts the token back on the hook they ring a bell. You hear the bell and run over to get the token. There is a chance that somebody else will beat you to it and you'll have to wait again. That's why you often see a loop when Using the nofityAll and Wait Metods.
 
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Every object in Java is automatically extended from the Java class hierarchy root, Object class and has single lock. If multiple threads are synchronized on any single object’s lock, then these threads need to be coordinated on that object’s lock according to our requirements and this is the situation when the wait(), notify() and notifyAll() methods are come into the scenes. Thus, every object in Java need to be equipped with three thread related methods: wait(), notify(), notifyAll(). To solve this problem, Object class is the only one place to define these three methods.
 
author
Posts: 23832
140
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

As already mentioned, the reason these methods are part of the Object class, is because any object can be used for synchronization, and hence, any object should be able to be used for notification. Having these methods as part of the Object class is, of course, better than the Thread class, in this regard.

However, there is a flaw. The flaw being that there isn't necessary a one to one mapping between a mutex and its condition variable. And the Java (synchronization, wait, notify) design enforces this. Prior to Java 5, this mapping is removed by classes designed just for being a lock and condition variables. At Java 5, the Lock and Condition class were added to deal with this.

So... IMHO, the answer should be that neither answer is correct. The best design, in retrospect, should have been something done entirely using classes.

Henry

 
Unmesh Chowdhury
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks sir, Mr. Henry Wong for your inevitable message in this critical context.
 
Ranch Hand
Posts: 162
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Superb Explanation.

 
Ranch Hand
Posts: 1164
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Henry Wong wrote:
As already mentioned, the reason these methods are part of the Object class, is because any object can be used for synchronization, and hence, any object should be able to be used for notification. Having these methods as part of the Object class is, of course, better than the Thread class, in this regard.

However, there is a flaw. The flaw being that there isn't necessary a one to one mapping between a mutex and its condition variable. And the Java (synchronization, wait, notify) design enforces this. Prior to Java 5, this mapping is removed by classes designed just for being a lock and condition variables. At Java 5, the Lock and Condition class were added to deal with this.

So... IMHO, the answer should be that neither answer is correct. The best design, in retrospect, should have been something done entirely using classes.

Henry



Hi Henry

I understood the first part of your explanation. However, I could not understand the flaw. What do you mean when you say that, "there isn't necessarily a one to one mapping between a mutex and its condition variable"? Please explain.

Regards
Mansukhdeep
 
Henry Wong
author
Posts: 23832
140
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Mansukhdeep Thind wrote:
I understood the first part of your explanation. However, I could not understand the flaw. What do you mean when you say that, "there isn't necessarily a one to one mapping between a mutex and its condition variable"? Please explain.



The classic example is that of a bounded blocking queue. It has a single mutex lock to deal with all accesses to it. And threads need to wait on it; for data to be added if it is empty; and for data to be removed if room is needed. Two possible waiting conditions and one lock. Perfect for setting two condition variables that share a single mutex lock.

Henry
 
Villains always have antidotes. They're funny that way. Here's an antidote disquised as a tiny ad:
ScroogeXHTML - small and flexible RTF to HTML converter library
https://coderanch.com/t/710903/ScroogeXHTML-RTF-HTML-XHTML-converter
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!