Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Trouble with Thread Question  RSS feed

 
Trey Carroll
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I need some help with a Thread question that was originally raised in the SCJP forum, but that went for a month and 1/2 without a satisfactory answer.

Original post

For the sake of convenience I will repost the relevant parts here. It began with a question from Sun's pre-evaluation test:


5. class Order implements Runnable {
6. public void run() {
7. try { Thread.sleep(2000); } catch (Exception e) { }
8. System.out.print("in ");
9. }
10. public static void main(String [] args) {
11. Thread t = new Thread(new Order());
12. t.start();
13. System.out.print("pre ");
14. try { t.join(); } catch (Exception e) { }
15. System.out.print("post ");
16. } }


The issue is that the correct answer seems to be both: 1) in pre post and 2) pre in post

Output 2 is easy to understand, but output 1 just doesn't make any sense to me. I understand the principle of no-guarantees with Thread behavior. However, I need to clearly understand which behaviors are guaranteed and which are JVM dependent.

In the previous post someone has stated that a JVM is free to ignore a call to sleep. However, the K&B 1.5 page 699 seems to contradict this:

sleep() is guaranteed to cause the current Thread to stop executing for at least the specified sleep duration.


If the statement that the JVM may choose to ignore a call to sleep() then I have no problem with the "in pre post" output. Yet if the K&B book is correct that the sleeping behavior is guaranteed, then it seems absurd that the main Thread would sit in the runnable pool unselected by the Thread scheduler during the entire 2,000+ milliseconds that Thread t will spend in the waiting/sleeping/blocking state! Or is the no-guarantees principle simply telling us that we can never predict what the Thread scheduler will do; that it could indeed sit idly, never selecting Thread main during the time Thread t is sleeping?

Any clarification that you can provide would be greatly appreciated.

In summary, I need to know if a JVM is free to ignore a call to sleep and whether my reasoning for the "in pre post" output is valid.

Thank you,
[ October 01, 2008: Message edited by: Trey Carroll ]
 
Paul Beckett
Ranch Hand
Posts: 96
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If the statement that the JVM may choose to ignore a call to sleep() then I have no problem with the "in pre post" output. Yet if the K&B book is correct that the sleeping behavior is guaranteed, then it seems absurd that the main Thread would sit in the runnable pool unselected by the Thread scheduler during the entire 2,000+ milliseconds that Thread t will spend in the waiting/sleeping/blocking state! Or is the no-guarantees principle simply telling us that we can never predict what the Thread scheduler will do; that it could indeed sit idly, never selecting Thread main during the time Thread t is sleeping?


The sleep behaviour is guaranteed (unless the thread is interrupted). I think the point of the sample question is to get you to understand that the "main" thread is not guaranteed to return to the running state during the "order" threads sleep time. I'm sure in most jvm's under most invocations the output will be "pre in post" with the 2000millisecond sleep - but this is not guaranteed.

The output "in pre post" is easier to understand if you change the sleep time to 1millisecond.
 
Henry Wong
author
Sheriff
Posts: 22840
119
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I hate questions like this... They really push the limits of common sense in the Java specification.

"Spurious Interrupts" are allowed in the specification, because some OSes may not be able to implement it correctly. Not having a guarrantee to the thread scheduler is so that it can be mapped onto all the native threading models. But c'mon ....

I highly doubt that there is a single case that can't handle an interrupt correctly -- for a 10 line program that doesn't use interrupts! I also highly doubt that there is a single native thread model out there that can't timeslice to the only runnable thread in the program, in under two seconds!

IMO, I agree with all the posters who thinks that there is only one valid answer.

Henry
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!