yield() in synchronized code - a Dan Chisholm question

[Julian Reed]

I wanted to clarify my logic for why the following code works the way that it does:
First the code:

 
class A extends Thread {
  private C c1;
  public A(String s1, C c1) {super(s1); this.c1 = c1;}
  public void run() {
    for (int i = 0; i < 3; i++) {
      System.out.print(currentThread().getName() + c1.getI());
    }
  }
}
class C {
  private int i;
  public synchronized int getI() {
    int oldValue = i;
    Thread.yield();
    i += 1;
    return oldValue;
  }
  public static void main (String[] args) {
    C c = new C();
    Thread t1 = new A("X", c);
    Thread t2 = new A("Y", c);
    t1.start();
    t2.start();
  }
}

The answers are:
a. Prints: X0Y1X2Y3X4Y5.
b. Prints: X0X1X2Y3Y4Y5.
Initially, I presumed that the a yield() call would mean that either thread would take the lock of the object with it, so that the second thread could not enter the synchronized method since it can't acquire the lock.
Does this mean that because the second thread is blocked on the object and therefore sits in the waiting list for that object, that the thread scheduler allows the first thread to continue without a yield() call and therefore releases the lock in the synchronized method?
Thanks for any help!

[Dan Chisholm]

Julian,
Thank you for using my exam.
The following are all of the answer options for the question.

What are the possible results of attempting to compile and run the program?
a. Prints: X0Y1X2Y3X4Y5.
b. Prints: X0X1X2Y3Y4Y5.
c. Prints: X0Y0X1Y1X2Y2.
d. Prints: X0X1X2Y0Y1Y2.
e. Compiler error.
f. Run time error.
g. None of the above.

Since the method is synchronized we know that the value returned by the method will be unique. In other words, both threads will never read the same value. Therefore, answer options c and d can be eliminated. Both answer options 'a' and 'b' are possible because the thread scheduler could allow the two threads to run in any order.
The behavior of the Thread.yield method is platform dependent. There is no guarantee that Thread.yield will cause the running thread to allow a different thread to run.
This is really not a question about the Thread.yield method. I just put it in there so that if you run the program you will be more likely to see a wider variety of results.
The real exam does not emphasize the Thread.yield method. Just remember that the behavior is platform dependent.

[Julian Reed]

Dan
Thanks for your reply, I understand now!
Kind Regards
Julian

[Giselle Dazzi]

Hi,
But Im still in doubt if calling yield will release the lock or not ....

[William Brogden]

The Thread yield() can not release a lock.
Bill

[Giselle Dazzi]

Therefore, answer options c and d can be eliminated. Both answer options 'a' and 'b' are possible because the thread scheduler could allow the two threads to run in any order.

I agree but If yield does not release the lock, whichever thread starts first will finish before the other gets a chance to hold the lock, so for me the answer would never be
X...Y.. X.. Y...
only
X..X..X.. Y..Y..Y..
or
Y..Y..Y.. X..X..X..
Does that make any sense ?

[Dan Chisholm]

Originally posted by Giselle Dazzi:

I agree but If yield does not release the lock, whichever thread starts first will finish before the other gets a chance to hold the lock, so for me the answer would never be
X...Y.. X.. Y...
only
X..X..X.. Y..Y..Y..
or
Y..Y..Y.. X..X..X..
Does that make any sense ?

Giselle,
The getI method is synchronized, but the run method is not. The loop that iterates from 0 to 3 is in the run method so nothing stops both threads from iterating simultaneously. The thread scheduler could allow thread X to run only one loop iteration before allowing thread Y to run only one loop iteration. That sequence of events to repeat three times.

[Giselle Dazzi]

Thank you Dan.
When I think Im starting to know a little ...

[Ryan Wilson]

When I run the code I get the following output
Y1X0X3Y2Y5X4
Is this because thread X completes the getI() method and then leaves the running state. Thread Y then completes the run method and prints Y1, then X completes run by printing X0.
I understand that little is guaranteed when talking about the scheduler. In the case above it appears that thread x stops just before it completes the print statement. Can I assume that a thread can leave the running state at any point in execution, meaning even if it has not completed the current statement?
Or am I missing something?