Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Food for thought question (Threads related)

 
Manasa Rao
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 263
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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"
Sheriff
Posts: 8521
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Moving to the Threads forum.
 
John Lee
Ranch Hand
Posts: 2545
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 2987
12
Firefox Browser IntelliJ IDE Java Mac Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 18214
53
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
... 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.
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic