• Post Reply Bookmark Topic Watch Topic
  • New Topic

Why in java.lang.Object?

 
Raghavan Muthu
Ranch Hand
Posts: 3381
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.
 
Jeroen T Wenting
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.
 
Corey McGlone
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 ]
 
Stan James
(instanceof Sidekick)
Ranch Hand
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: 3381
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)
Ranch Hand
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.
 
Unmesh Chowdhury
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.
 
Henry Wong
author
Sheriff
Posts: 22532
109
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.
 
Bennet Xavier
Ranch Hand
Posts: 162
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Superb Explanation.

 
Mansukhdeep Thind
Ranch Hand
Posts: 1163
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
Sheriff
Posts: 22532
109
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
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!