Changing the class those methods are associated with will not necesseraly change the mechanism in which they work. It would change the way you would use them. Right now you can use an arbitrary object as a lock and signal, which is very flexible. Associating the wait and notify methods with the Thread class would very much limit how and when you have access to those methods.
Howsoever I am not satisfied with the answer. My only question about it is that do object level wait & Notify methods will still come in picture if these methods are in Thread class. They may come into picture when Multi threading comes into action. But what play does Object class miss.
Again, if they are not in Object class, what features or rather say 'Power' will Object class miss.
Kewat Ajay wrote:Mathew,
I agree to your point that, it is required to coordinate between multiple threads, but why is it at the Object level?
Why not at the Thread level ??
Because when they are in the Object class you can have arbitrary objects as locks. You use locks as a means of protecting data, you can have lots of different data, and you can have different locks to protect different data. You can use the object holding the data to protect the data, for example. And you can create inter thread communication when you don't have data. And you can do all of this without needing to know about what thread is executing what code and what other threads are doing.
Well, as I already said, it's now up to you to explain how exactly how it would work under your proposal. In particular, how would it work differently? What would have to be done to existing code to make it work in the same way if your proposal was accepted?
I am now aware about the thread communication which happens at the Object level "locks"..... & not at the Thread level, this clarifies my doubt. Why i asked this question as It was asked to me in one of my java interviews. I wanted to know the reason.
There are certainly other ways that these methods cold have been organized, and many of us feel that Object isn't really the best place for these methods. I don't think Thread is either - I think they should be in separate classes entirely, which is the approach taken in newer concurrency constructs such as java.util.concurrent.locks.Lock and java.util.concurrent.Future.