• Post Reply Bookmark Topic Watch Topic
  • New Topic

Thread Methods  RSS feed

 
Georg Nieuwoudt
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Yall!

The 3 Methods wich threads use in the Object class namely wait(), notify() & notifyAll() is native... Thats all swell, but now a Question arises when i ponder on the thought!

Question :
"The Threads trying to obtain a Lock on the Monitor of a specific Object, when they get notified does the JVM decide wich Thread is to obtain the lock next, or does the OS decide(hence the 3 methods being native)?"

Any clarification on this subject will be much apreciated, and in advance i'd like to thank whoever for their input...
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'll put my money on the OS. I imagine if the JVM decided it would be what was called 'green threads.'
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's generally a bad idea to try to get deep into the underpinnings of Java threads. The whole point of the Java abstraction is to avoid doing so. The API documentation, language and JVM specifications tell you what you can and can't assume about threads.

With regard to which thread gets woken up next, there are no strong guarantees. I believe that you are guaranteed that scheduling of threads with the same priority will be "fair", when measured over a long period. That's about it.
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was taught in my classes there was no guarantee or claim of fairness.
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by CL Gilbert:
I was taught in my classes there was no guarantee or claim of fairness.


Perhaps not, but surely it's just common sense that it has to be "reasonably fair". For instance, a threading implementation that, given two runnable threads of equal priority, gave all the CPU to one and none to the other, over a long period, would surely be considered broken. I wouldn't assume that the two threads would get identical amounts of CPU, but I really would hope that they'd get similar amounts, over a long period.
 
Henry Wong
author
Sheriff
Posts: 22853
119
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Peter Chase:

Perhaps not, but surely it's just common sense that it has to be "reasonably fair". For instance, a threading implementation that, given two runnable threads of equal priority, gave all the CPU to one and none to the other, over a long period, would surely be considered broken. I wouldn't assume that the two threads would get identical amounts of CPU, but I really would hope that they'd get similar amounts, over a long period.


There is nothing in the specification about the order of granting the locks, so it is completely non-deterministic. For 99.44% of the time, it is not a problem. And it is never a problem with only a couple of threads.

For the case where it is a problem, Java 1.5 has a "fairness" flag on the ReentrantLock (and Condition) class that provides close to FIFO ordering.

Hope this helps,
Henry
[ November 18, 2004: Message edited by: Henry Wong ]
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!