Randomness of 'the thread scheduler'

[ce orto]

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?

class MyRunnable implements Runnable {
	public void run() {
		go();
	}
	public void go() {
		doMore();
	}
	public void doMore() {
		System.out.println("top o' the stack"); 
	}
}

public class ThreadTester {			
	public static void main(String[] args) {
		Runnable threadJob = new MyRunnable();
		Thread myThread = new Thread(threadJob);
		
		myThread.start();
		System.out.println("back in main"); 	
	}
}    

[Henry Wong]

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]

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]

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]

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.