Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Why wait(), notify(), notifyAll() declared in Object class?  RSS feed

 
Rituparna Duttagupta
Ranch Hand
Posts: 55
Firefox Browser Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi friends,
why is it that wait(), notify(), notifyAll() methods have been declared in the Object class and not in the Thread class? Is it possible to call these methods on the main thread?

If we create a thread by a Runnable instance, then how could we access the methods of the Thread class?? can we import java.lang.Thread?
 
Rob Spoor
Sheriff
Posts: 21048
85
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rituparna Duttagupta wrote:Hi friends,
why is it that wait(), notify(), notifyAll() methods have been declared in the Object class and not in the Thread class? Is it possible to call these methods on the main thread?

Please SearchFirst. I this question has been asked quite a few times before.

If we create a thread by a Runnable instance, then how could we access the methods of the Thread class?? can we import java.lang.Thread?

Thread.currentThread() returns a reference to the (surprise surprise) current Thread.
 
Jim Hoglund
Ranch Hand
Posts: 525
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rituparna: These behaviors correctly belong to Object because
it is objects that must be protected from unwanted changes. Java
allows you to lock any object, even:

Object lockObject = new Object();

Jim ...
 
Henry Wong
author
Sheriff
Posts: 23279
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jim Hoglund wrote:Rituparna: These behaviors correctly belong to Object because it is objects that must be protected from unwanted changes. Java allows you to lock any object


Here is an excerpt from another topic -- my response to whether the Object class or the Thread class is the correct place for these methods.

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
 
Rituparna Duttagupta
Ranch Hand
Posts: 55
Firefox Browser Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thank you all, i got my answer now.
 
Suhaas Mohandos
Greenhorn
Posts: 21
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry for waking up an old thread. Didn't want to start a new one.

They say that wait, notify should be part of the Object class because threads don't know about each other.

But my question is the Object class being the super class of all classes also dont know about threads and thread objects since my understanding is super class don't know about child classes while it is possible the other way round.

So how does it make sense to have wait and notify in Object class and how does having wait and notify in super class make sense?

I am confused.
 
Stephan van Hulst
Saloon Keeper
Posts: 7719
142
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Putting wait() and notify() in the Object class makes sense if you use any old member to synchronize on. For instance:

The pop() method blocks until there is at least one element to return. Since the waiting condition depends on the state of the stack member, it makes sense to call the wait() method on the stack member. Essentially we're saying: "While the stack is empty, wait for something to happen to the stack".

Now, with Java's newer concurrency library, this is no longer the best way to do this. You should explicitly create lock objects and waiting conditions. This is the new way to do things:

If Java had provided Lock and Condition from the beginning, Object would no longer need the wait(), notify() and notifyAll() methods.
 
Suhaas Mohandos
Greenhorn
Posts: 21
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No, I didn't get my answer in the previous post. Lets stick to the old method of doing it.

Why not have the wait, notify and notifyall in Thread class?
 
Stephan van Hulst
Saloon Keeper
Posts: 7719
142
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My previous post explained why. Because before Lock and Condition existed, you needed to be able to synchronize on any object. In my example, that object was a Deque, which is not a Thread.

It's important to realize that wait() doesn't mean "Make this thread wait". It means "Wait until this lock becomes available". Any object can act as a lock, so every object must support wait(), notify() and notifyAll().

You'll see that 'wait' is actually a bit of a misleading name. It should have been named 'await', which is actually what they called it in the Lock class.
 
Campbell Ritchie
Sheriff
Posts: 55351
157
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan van Hulst wrote:. . . If Java had provided Lock and Condition from the beginning, Object would no longer need the wait(), notify() and notifyAll() methods.
I read somewhere, probably here, that the methods are called await and signal (or something like that) because it is impossible to override the wait and notify methods. As you can see here, those methods are all final.
 
Stephan van Hulst
Saloon Keeper
Posts: 7719
142
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Even if those methods were not final, it would have been a mistake to override them for the Condition class, because Condition.await() does something different than Object.wait().

Object.wait() requires the current thread to own the object monitor. Condition.await() requires the current thread to own the lock associated with the condition, not the condition's object monitor.

Regardless, wait() was a bad name because it implied the object should wait. Instead, what really happens is that you wait on the object (or at least, it's intrinsic lock). await() implies that the object is the grammatical object of the verb, not the subject.
 
Stephan van Hulst
Saloon Keeper
Posts: 7719
142
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oh and I really should pick up a copy of Concurrency in Practice, it's been on my wish list for years!
 
Campbell Ritchie
Sheriff
Posts: 55351
157
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There were all sorts of mistakes in the earlier versions of Java®. This is a method with a misleading name and also with a misleading short description in the API documentation. A more recent example of a misleading name, which everybody seems to misunderstand, though the link says exactly and clearly what the method does.
 
Stephan van Hulst
Saloon Keeper
Posts: 7719
142
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why is getRGB() misleading?
 
Henry Wong
author
Sheriff
Posts: 23279
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan van Hulst wrote:
Regardless, wait() was a bad name because it implied the object should wait. Instead, what really happens is that you wait on the object (or at least, it's intrinsic lock). await() implies that the object is the grammatical object of the verb, not the subject.


Well, to be fair, the Java designers did not invent wait/notify -- as it is just a condition variable implementation. If you want to compare naming schemes, both POSIX and Solaris threads also used a variation of wait (and not await). And Windows condition variable naming used a variation of sleep...

And while grammar may be a somewhat good argument, I think familiarity is also a good argument too.

Henry
 
Campbell Ritchie
Sheriff
Posts: 55351
157
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan van Hulst wrote:Why is getRGB() misleading?
The fact that somebody doesn't see what is misleading makes it more misleading.

What does it return? It doesn't return RGB, but aRGB. Rather than the returned values being in the range 0...0xff_ff_ff, they are in the range 0...0xff_ff_ff_ff.
 
Suhaas Mohandos
Greenhorn
Posts: 21
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's important to realize that wait() doesn't mean "Make this thread wait". It means "Wait until this lock becomes available". Any object can act as a lock, so every object must support wait(), notify() and notifyAll().

That answer's my question.Thanks
 
Norm Radder
Ranch Foreman
Posts: 2220
28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
wait() doesn't mean "Make this thread wait". It means "Wait until this lock becomes available"

That sounds like what synchronized does.  The API doc for wait() says:
Causes the current thread to wait until another thread invokes the notify() method or the notifyAll() method for this object.

That sounds like it does make a thread wait.
 
Stephan van Hulst
Saloon Keeper
Posts: 7719
142
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wow, I must have had a massive brain-fart when I wrote what I did. I know what I wanted to express, but the words I chose are completely misleading and technically wrong. Right now I don't know how to explain it better than the line that Norm quoted from the API.

Please have some cows for calling me on some really bad stuff Norm.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!