Question from k&B's masterexam about yield()???????

[Deep Chand]

Which three guarantees that thread leaves the running state?
a) sleep(5000)
b) activeT.join()
c) notify()
d) notifyAll()
e) wait()
f) yield
i choose a, e, f. I chose F based on the other discussion thread that I started about yield(). However the answer in the exam is a, e, b. The reason they have given for F being the wrong answer is:
"The yield method is not guaranteed to cause a thread to leave the running state, although if there are threads with the same priority as the currently running thread then the current thread will probably leave the running state. "
I didn't choose B because how would you know whether activeT is live or not. But in the answer explanation is given 'assuming that the thread is alive' ...if that is the case why can't we assume that currently running thread has lower priority than the one's in the runnable state.
So for the purpose of real exam, what is the answer? Kathy or Bert would be able to clarify on this issue I guess :-)
Thanks,
Deep

[Damien Howard]

You can assume the currently running thread is lower priority if you wish, but that doesn't change the answer because the yeild method is jvm dependent. If yield is called then the running thread should leave the run state to allow a higher priority thread to run, but it doesn't have to. It is up to how the jvm was designed and thus you have no guarantee.

[Deep Chand]

Ok. So are we saying that yield() doesn't guarantee that it will leave the running state. It will only leave the running state iff there are other threads with higher or equal priority in runnable state and again that is jvm dependent. So it is very possible that the current thread never leaves the running state even if we signal the jvm 100 times. So, a, e, b are right. Am I correct?
But again if we are given an option about activeT.join(). Can we assume for the exam that activeT is alive.
Thanks,
Deep

[Damien Howard]

I don't know if you can assume that or not, but I can say I didn't have any ambiguous questions whatsoever when I took the exam. I don't know about others.

[Steve Lovelace]

I had the same hesitation about activeT.join(). You are forced to make an assumptiona based only on what the variable name suggests. Very shakey. But I chose it by process of elimination. For sure, yield() does not guarantee anything. (by the way, using Smalltalk a decade ago, there was also a yield method - same problem. Virtual machines are always at the mercy of the OS to some degree, and certainly are when they opt to use OS scheduling facilities.)

[Marlene Miller]

I would say none of the options guarantee that the thread leaves the running state.
According to Doug Lea, Let T be a thread executing the wait method on object M... One of the following actions occurs... If thread T is interrupted, an InterruptionException is thrown and T's interruption status is set to false. Otherwise, the following sequence occurs. 1. Thread T is added to the wait set of object M (et cetera)
The join method invokes the wait method so the same applies to join. Sleep is similar to wait, so the same probably applies.
According to Doug Lea, Thread.yield is a purely heuristic hint... The JVM may interpret this hint any way it likes.

[Barkat Mardhani]

Posted by Marlene:

I would say none of the options guarantee that the thread leaves the running state.

I would say sleep(3000) will definitely put out current thread of running state for 3 seconds.
Also wait() will definitely wait the current thread until interrupted.
[ September 16, 2003: Message edited by: Barkat Mardhani ]

[Barkat Mardhani]

Posted by Damain:

You can assume the currently running thread is lower priority if you wish, but that doesn't change the answer because the yeild method is jvm dependent. If yield is called then the running thread should leave the run state to allow a higher priority thread to run, but it doesn't have to. It is up to how the jvm was designed and thus you have no guarantee.

I think purpose of yield is to allow 'same priority thread' not higher priority threads. Higher priority threads will most probably pre-empt the currently running low priority thread without even issuing yield.
Problem with yield is as follows:
The currently running thread will go into runnable threads pool with other same priority runnable threads already waiting there. And jvm will pick one of them to run. There is a possiblity that same thread is picked. Therefore there is no gurrantee.
I agree that option b in grey area.
Thanks
Barkat

[Marlene Miller]

class R implements Runnable {
   public void run() {
      Thread t = Thread.currentThread();
      try {
         System.out.println(
            System.currentTimeMillis() + " " + t.isInterrupted());
         Thread.sleep(3000);
      } catch (InterruptedException e) {
         System.out.println(
            System.currentTimeMillis() + " " + t.isInterrupted());
      }
   }
}
class Test {
   public static void main(String[] args) {
      R r = new R();
      Thread t = new Thread(r);
      t.start();
      t.interrupt();
   }
}
1063760586482 true
1063760586482 false

In this example, the interruption status is true before Thread-1 calls sleep. The timestamp suggests that the thread never slept.
We cannot know whether the scheduler changed the state of the thread from runnable to blocked unless we read the source code. One possibility is, the sleep method checked the interruption status (== true), set it to false and threw an InterruptedException.
[ September 16, 2003: Message edited by: Marlene Miller ]

[Anupam Sinha]

I would say none of them.
a) sleep(5000) : - If InterruptedException has already been thrown then the thread would go into the sleep mode.
b) activeT.join() : - The thread activeT might already have completed and there might not be anything to wait for.
e) wait() : - Same as a.
f) yield() : - No gaurantee that there is any thread the this thread should yield to.

[Kathy Sierra]

Well, I know *one* question we're gonna delete in the next version
There won't be a question *quite* this fuzzy on the exam. I will say that in the intro to the exam, it does say that you are to assume that anything you do NOT see is working normally, as expected. In other words, you are to imagine that if there is a variable, it has been properly initialized, unless otherwise stated.
So, that was our intent when we said, "activeT" -- so that you would KNOW that the thread you were joining with had in fact NOT yet completed. But this is pretty weak (and doesn't explain the InterruptedException issue -- which I'll get to in a moment).
Most of the time in the *real* exam, we tried to be explicit about that, by saying things like:
Given <stuff>
and assuming that <variable> has been properly initialized...
Still, all of the programming exams (SCBCD, SCJP, SCWCD) do use variables that have not been *demonstrated* to have been properly initialized, but yet you are required to assume that they do in fact hold what they claim to, either by their name, or even by context. So if I were taking a Sun exam, I would definitely have assumed that activeT was an active thread. But I wouldn't worry, because as I said, the real exam doesn't have anything that ambiguous. They've all been long since 'pruned' from the 1.4 test, now that so many people have taken it!
However, that still doesn't really work for this question, because the way it is worded does not give enough information with respect to the InterruptedException. It would have to be changed to something like:
"Assuming an InterruptedException is not (and has not been) thrown, which of the three will cause the thread to leave the running state?"
So, you're all correct -- it's just a poorly-worded question, so it really doesn't work. If i were to completely change the wording, what do you think about this (I know it's awkward, but we don't have much to work with on edits)
"Given that no InterruptedExceptions are (or have been) thrown, and that activeT is a Thread which is still Runnable, which of these guarantee that a thread will leave the running state?"
I think the main point we were trying to test is whether you understood that yield() is only a suggestion, not a guarantee of anything.
Anyway, thanks and sheesh-- I hope that you will at least consider our bad question a 'learning opportunity' Then we can pretend that, why yes, that was our intent all along!
Cheers and thanks for the help!! And sorry for the confusion. The folks who've taken the exam are right -- if you know the content, the real exam questions are not ambiguous. But do remember the, "Assume everything else you don't see is working correctly". Because remember, virtually ANYTHING on the exam could fail if you were to imagine things like, "Well, they didn't actually SAY that the JVM or compiler were configured properly into their OS..." Or, they didn't SAY that they used a proper editor -- like, they didn't actually state that they didn't write this in RTF..." So, you could take it to the extreme unless you assme that "everything else is working..."
The only time I've seen this really become an issue is with Assertions, where the question (although I think we may have fixed all of these), might not explicitly say whether assertions are enabled. But if the question says, "Which of these will cause assertions to run only for classes within..." you are to assume, "if assertions are enabled."
The exam is tricky, but we didn't try to deliberately catch you on things like that.
If we want to test you on whether you know that assertions aren't enabled by default, then the question will explicitly ask you if assertions are enabled or disabled by default!
-Kathy

[Barkat Mardhani]

Posted by Marlene:

code:
--------------------------------------------------------------------------------
class R implements Runnable { public void run() { Thread t = Thread.currentThread(); try { System.out.println( System.currentTimeMillis() + " " + t.isInterrupted()); Thread.sleep(3000); } catch (InterruptedException e) { System.out.println( System.currentTimeMillis() + " " + t.isInterrupted()); } }}class Test { public static void main(String[] args) { R r = new R(); Thread t = new Thread(r); t.start(); t.interrupt(); }}1063760586482 true1063760586482 false
--------------------------------------------------------------------------------

In this example, the interruption status is true before Thread-1 calls sleep. The timestamp suggests that the thread never slept.
We cannot know whether the scheduler changed the state of the thread from runnable to blocked unless we read the source code. One possibility is, the sleep method checked the interruption status (== true), set it to false and threw an InterruptedException.

Hi Marlene:
The statement in bold is not gauranteed. There is 1 in 1000 chance that it will not be the case. The code below will print 1.

 class A implements Runnable {
Object obj;
boolean showstoper   = false;
public A(Object obj) {this.obj = obj;}
public void run() {
synchronized(obj) {
showstoper = true;
//System.out.println("Run started");
//System.out.println("Run is going to sleep");
//try { Thread.sleep(3000); } catch(InterruptedException ie) { }
//System.out.println("Run woke up");

}
}
}
class Test {
static int count;
private void m1() {
A a = new A(this);
Thread t1 = new Thread(a);
t1.start();
synchronized (this) {
try { assert (!a.showstoper) ;} catch(AssertionError ae) {count++;}
//System.out.println("Main continued");
//System.out.println("Main is going to sleep");
//try { Thread.sleep(3000); } catch(InterruptedException ie) { }

//System.out.println("Main woke up");


}
}
public static void main (String[] args) {
for (int i = 0 ; i<1000; i++)
new Test().m1();
System.out.print("Count= "+count);
}
}
 

[Marlene Miller]

Hi Barkat. Thank you for your comments on my example.
I think what you are showing me is when one thread creates another thread, after that either thread could execute. Yes, I agree. In my example, the main thread could invoke interrupt() or the other thread could invoke sleep().
I don�t care about the case when the other thread calls sleep() before the main thread calls interrupt(). We all know what happens then. The other thread sleeps.
I wanted the main thread to go first without a lot of fancy code. So I relied on chance. I wanted to show that IF the interruption status is set, it appears the thread does not sleep.
That's why I call isInterrupted() before calling sleep(). I want to make sure I have the right case.
Marlene
[ September 17, 2003: Message edited by: Marlene Miller ]

[Marlene Miller]

Thank you Kathy for the insights and the arbitration.