Win a copy of Practical SVG this week in the HTML/CSS/JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Randomness of 'the thread scheduler'

 
ce orto
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Below code should execute printlns (one from main() stack, other from run() stack) randomly (according to page 498, HF Java), but it does NOT. Does this have anything to do with Core2Duo™ processor? Besides, the original code (page 494) has MyRunnable public and ThreadTester not (I've turned that around so it "works" ): is this a mistake or am I missing something?
 
Henry Wong
author
Sheriff
Posts: 22542
109
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Below code should execute printlns (one from main() stack, other from run() stack) randomly (according to page 498, HF Java),


Really?!? Does the book really say the order is random? Or does the book say that the order is undefined?

Henry
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24213
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
ce orto wrote: Besides, the original code (page 494) has MyRunnable public and ThreadTester not (I've turned that around so it "works" ): is this a mistake or am I missing something?


The source file has to be named after whichever class you make public, but otherwise, the program is correct either way. It would also be correct if neither class were public.

And as Henry implies, if the book says the order is "random", it's just being imprecise. The order is undefined and (on most Java implementations) technically indeterminate; although for any given implementation, it's quite likely that virtually all runs will print these lines in the same order.
 
ce orto
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henry Wong wrote:
Below code should execute printlns (one from main() stack, other from run() stack) randomly (according to page 498, HF Java),


Really?!? Does the book really say the order is random? Or does the book say that the order is undefined?

Henry


»[Two arrows pointing to the console output] Notice how the order changes randomly. Sometimes the new thread finishes first, and sometimes the main thread finishes first.«

Ernest Friedman-Hill wrote:
ce orto wrote: Besides, the original code (page 494) has MyRunnable public and ThreadTester not (I've turned that around so it "works" ): is this a mistake or am I missing something?


The source file has to be named after whichever class you make public, but otherwise, the program is correct either way. It would also be correct if neither class were public.

And as Henry implies, if the book says the order is "random", it's just being imprecise. The order is undefined and (on most Java implementations) technically indeterminate; although for any given implementation, it's quite likely that virtually all runs will print these lines in the same order.

Thank you. I was just curious, whether there is any pattern in the low-level process that yields such undefined (random ) order.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24213
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
ce orto wrote:
Thank you. I was just curious, whether there is any pattern in the low-level process that yields such undefined (random ) order.


It totally depends on the JVM implementation. Many (but not all) JVMs use the host OS's thread facility these days. On Windows, I believe one JVM thread corresponds to one OS thread, so it's completely up to the Windows thread scheduler. On Solaris, the JVM uses LWPs ("fibers") which are like sub-threads within a thread; I think it's up to the JVM to do scheduling among LWPs (although again, I'm not sure, these things change over time.) Henry might have more up-to-date information on specific implementations. But in any case, the short answer is you really can't tell what's going to happen; you should design the program for any contingency.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!