Why in java.lang.Object?

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.

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.

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 ]

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.

Thanks a lot for Joreon, Corey and James!
The justification/reason was excellent.

Thanks,
Raghavan alias Saravanan M.

To clarify a bit what Cory said: In Java you're effectively ALWAYS working multithreaded (even if you may not notice).

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.

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.

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

Thanks sir, Mr. Henry Wong for your inevitable message in this critical context.

Superb Explanation.

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

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