File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Threads and Synchronization and the fly likes Food for thought question (Threads related) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Food for thought question (Threads related)" Watch "Food for thought question (Threads related)" New topic

Food for thought question (Threads related)

Manasa Rao

Joined: Apr 07, 2003
Posts: 6
Why are "wait()", "notify()" and "notifyAll()" methods in java.lang.Object class rather than in java.lang.Thread?
Thanks in advance.
aadhi agathi
Ranch Hand

Joined: Apr 29, 2002
Posts: 263
because of a principle called as "object locking".
plus it is an architectural decision to have all the java objects be thread safe.

Cindy Glass
"The Hood"

Joined: Sep 29, 2000
Posts: 8521
Moving to the Threads forum.

"JavaRanch, where the deer and the Certified play" - David O'Meara
John Lee
Ranch Hand

Joined: Aug 05, 2001
Posts: 2545
Originally posted by Manasa Rao:
Why are "wait()", "notify()" and "notifyAll()" methods in java.lang.Object class rather than in java.lang.Thread?
Thanks in advance.

I think it is just a way to do it.
Greg Charles

Joined: Oct 01, 2001
Posts: 2967

As an example, let's say you are developing a thread-safe queue class. You have a write method that puts an object into the queue, and a read method that takes an object out. Both methods adjust indexes, the object count, and possibly even reorder the elements in the case of a priority queue.
OK, a reader thread calls the read method, but the read method finds that the queue is empty. It wants to tell the thread that it should wait for something to be written. The read method is synchronized, so it just needs to include the line:
If the wait method was on the thread class, it would be necessary to write:
Which way is easier? Wait, it gets worse. A writer thread comes in and writes an object to the queue. When it's done, it wants to notify any readers waiting for on empty queue that it's time to get busy reading. Therefore the write() method contains the line:
(Actually, notifyAll() is safer since I haven't distinguished between waiting readers and waiting writers.)
If notify was a method in the thread class, the code would be:
I'm not even sure how notifyAll() could be implmented. It obviously couldn't be a call on an individual thread.
So you can see, even though wait() and notify() seem to be methods affecting threads, it is much easier to write code when they are part of the Object class.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 17410

... Or, to say it shorter:
Locking a chunk code doesn't really gain you anything. Code exists to manipulate objects. So what you really are trying to do is regulate changes to the objects.
The finer degree of control you can have on locking, the less time your apps will be spent hung up on waiting. So if you lock only the object(s) of interest, other threads can continue on, even possibly using that same code, but on different objects.

An IDE is no substitute for an Intelligent Developer.
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

Because you lock with respect to a certain object, not a certain thread. Locks give you safe access to an "object", so locks have to work with the object. A thread is not an object, but an execution point.
Notwithstanding, a "Thread" (with a capital T) is a class which can be an object, its only used to communicate with and represent in some respects, the underlying "thread" (with a lower case t).
I agree. Here's the link:
subject: Food for thought question (Threads related)
It's not a secret anymore!