aspose file tools*
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
Author

Food for thought question (Threads related)

Manasa Rao
Greenhorn

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.
Manasa
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.


Aadhi
Cindy Glass
"The Hood"
Sheriff

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.
Manasa


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

Joined: Oct 01, 2001
Posts: 2851
    
  11

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:
wait();
If the wait method was on the thread class, it would be necessary to write:
Thread.currentThread().wait();
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:
notify();
(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:
Thread.getFirstThreadWaitingFor(this).notify();
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: 16065
    
  21

... 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.


Customer surveys are for companies who didn't pay proper attention to begin with.
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: http://aspose.com/file-tools
 
subject: Food for thought question (Threads related)