Why does this count down to zero and not to 1

[Ted North]

public class Stubborn implements Runnable {
             static Thread t1;
             static int x = 5;
             public void run() {
               if(Thread.currentThread().getId() == t1.getId()) shove();
               else push();
             }
            static synchronized void push() { shove(); }
            static void shove() {
              synchronized(Stubborn.class) {
                System.out.print(x-- + " ");
                try { Thread.sleep(2000); } catch (Exception e) { ; }
                if(x > 0) push();
            } }
            public static void main(String[] args) {
              t1 = new Thread(new Stubborn());
              t1.start();
              new Thread(new Stubborn()).start();
          } }

Possible answers from the practice exam:

> A compilation fails
> B The output is 5 4 3 2 1
> C The output is 5 4 3 2 1 0
> D The program could deadlock.
> E The output could be 5, followed by deadlock.
> F If the sleep() invocation was removed, the chance of deadlock would decrease.
> G As it stands, the program can’t deadlock, but if shove() was changed to synchronized, then the program could deadlock.


This is from OCP Exam 2 by K and B. The question is number 16. I am not sure why the output includes zero, 5 4 3 2 1 0, when the the boolean test at line 13 says (x > 0)... Is this because there are multiple threads running?

Also, the answers states: C is correct. It might look like this code could deadlock, but there is only one lock, so no deadlock can occur.

Is the lock referred to in the answer any Stubborn class instance?







Respectfully,

TN - powerhouse of industry and IT - humble admirer of RuntimeExceptions

[Praveen Kumar M K]

This is from OCP Exam 2 by K and B. The question is number 16. I am not sure why the output includes zero, 5 4 3 2 1 0, when the the boolean test at line 13 says (x > 0)... Is this because there are multiple threads running?

How about trying without the invocation in line 18. That should answer this question.

Is the lock referred to in the answer any Stubborn class instance?

Not any, but the one used in line 10 in the sync block.

[Ted North]

Praveen Kumar M K wrote:

Ted North wrote: This is from OCP Exam 2 by K and B. The question is number 16. I am not sure why the output includes zero, 5 4 3 2 1 0, when the the boolean test at line 13 says (x > 0)... Is this because there are multiple threads running?

How about trying without the invocation in line 18. That should answer this question.

Also in regards to printing to zero, why does the program stop printing here and not go into negative numbers or something?
I am going to try and remove the invocation at line 18 now to test your hypothesis.
***How can someone be able to look at this code and realize it will run to zero despite the logic seemingy to state that the program will only print to 1?

Praveen Kumar M K wrote:

Ted North wrote: Is the lock referred to in the answer any Stubborn class instance?

Not any, but the one used in line 10 in the sync block.

So at line 10 the Stubborn.class argument is making this method behave like a static synchronized method.

Thank-you for your response Praveen Kumar.

Respectfully,

TN - deleter of System32

[Ted North]

Praveen Kumar M K wrote:

This is from OCP Exam 2 by K and B. The question is number 16. I am not sure why the output includes zero, 5 4 3 2 1 0, when the the boolean test at line 13 says (x > 0)... Is this because there are multiple threads running?

How about trying without the invocation in line 18. That should answer this question.

You are right. When removing line 18 it only prints to 1.

Also, check out this program I made Praveen that does the same thing...which is printing to zero when the logic seems like it would only print to 1.

public class TestXLoop implements Runnable { 

	static int x = 5;
	
	public void run() {
	
	while (x > 0) { try { Thread.sleep(500); } catch(Exception e) {} System.out.print(x-- + " "); }
	}
	public static void main(String[] args) { 
		new Thread(new TestXLoop()).start();
		Thread tx = new Thread(new TestXLoop());
		tx.start();
	}
}

I guess this is what happens when there are two threads and flow-control.

Respectfully,

TN - milkyway local and javanaut

[Praveen Kumar M K]

Ted,

For the first program 5,4,3,2,1 is printed by thread t1(synchronization kicking in). On the last run, the value of x becomes zero. Now the second thread takes over and prints 0 first and then makes a check of (x>0) which becomes false. The problem(should I call it a problem?) here is the check being made after the print statement.

But in your second program you made the check before the print logic, so that does make things more clear.

However, looking at the explanation given with the answer in the Original Post, the discovery that we have made here is perhaps not the intended one. The answer is in the lines of deadlock concept, so I would suggest you to look at the code and verify whether it has to do with breaking(or making) any of the deadlock conditions.

[Helen Ma]

Ted North wrote:

public class Stubborn implements Runnable {
             static Thread t1;
             static int x = 5;
             public void run() {
               if(Thread.currentThread().getId() == t1.getId()) shove();
               else push();
             }
            static synchronized void push() { shove(); }
            static void shove() {
              synchronized(Stubborn.class) {
                System.out.print(x-- + " ");
                try { Thread.sleep(2000); } catch (Exception e) { ; }
                if(x > 0) push();
            } }
            public static void main(String[] args) {
              t1 = new Thread(new Stubborn());
              t1.start();
              new Thread(new Stubborn()).start();
          } }

Possible answers from the practice exam:

> A compilation fails
> B The output is 5 4 3 2 1
> C The output is 5 4 3 2 1 0
> D The program could deadlock.
> E The output could be 5, followed by deadlock.
> F If the sleep() invocation was removed, the chance of deadlock would decrease.
> G As it stands, the program can’t deadlock, but if shove() was changed to synchronized, then the program could deadlock.


This is from OCP Exam 2 by K and B. The question is number 16. I am not sure why the output includes zero, 5 4 3 2 1 0, when the the boolean test at line 13 says (x > 0)... Is this because there are multiple threads running?

Also, the answers states: C is correct. It might look like this code could deadlock, but there is only one lock, so no deadlock can occur.

Is the lock referred to in the answer any Stubborn class instance?



Deadlock may occur when two different objects are synchronized.
For example, in shove method:

 
    synchronized (objectA){
                    //do something 
          synchronized (objectB){ 
                      //do something
          }
    }

On the other hand, in push method:

      synchronized (objectB){
                    //do something 
          synchronized (objectA){ 
                      //do something
          }
    }

When two threads execute concurrently, one thread calls push and another thread calls shove.
Chances are good that the first thread locks objectB and waits for objectA and the second thread locks objectA (which 1st thread waits for) and waits for objectB (which 2nd thread waits for).
So, in the other words, 1st thread waits for objectA while 2nd thread locks it. The 2nd thread locks objectA , but does not release the lock for the 1st thread because the 2nd thread has not finish the synchronized block.

In your practice exam, the shove method calls push method and it looks like this:

    synchronized (Stuborn.class){

             synchronized (Stuborn.class){
           
              }

   }

Only the Stuborn.class object is locked. When there is only one object is locked, deadlock won't occur.

[Helen Ma]

Hi, Tedd
Regard to the zero issue, x-- prints the value of x before x is decreased by 1.

In this example, if t1 locks Stubborn.class object, it keeps calling shove, push, shove, push..... Here are the steps:
1. prints x=5
2. x=4, call push
3. push calls shove
4. prints x= 4
5. x =3, call push and so on.
6. print x = 1
7. x=0, stop
8. t2 locks Stubborn.class object because it is t2's turn now.
9. t2 prints x =0
10. x = -1 and stop

I hope these steps match with what Praveen posted previously.

[Ted North]

Helen Ma wrote:Hi, Tedd
Regard to the zero issue, x-- prints the value of x before x is decreased by 1.

In this example, if t1 locks Stubborn.class object, it keeps calling shove, push, shove, push..... Here are the steps:
1. prints x=5
2. x=4, call push
3. push calls shove
4. prints x= 4
5. x =3, call push and so on.
6. print x = 1
7. x=0, stop
8. t2 locks Stubborn.class object because it is t2's turn now.
9. t2 prints x =0
10. x = -1 and stop

I hope these steps match with what Praveen posted previously.

Does your program print -1?

Thank-you for stepping through the logic.

Respectfully,

TN

[Helen Ma]

I haven't tried to run the program. But from the code, it eventually prints x = 0 , x is decreased by 1, x = -1 , then it stops as it fails x>0 condition.

[raju salla]

hi,
Here first thread completes execution by printing the output 5 4 3 2 1 and then the condition fails at the if condition. Then the second thread starts execution, at this point x value is 0 then it will print 0 then it will test the if condition, then it returns false. Then the execution stopped and the result is 5 4 3 2 1 0.

[Ted North]

Hello JavaRanch,

Aren't there two locks in this tricky program? One lock in the synchronized block with the Stubborn Class object and one with the static synchronized push() method. Both of these lock on a Stubborn class object...

Why will dead-lock will not occur?

- Just trying to make sure I have this absolutely clear, so I can do better on future practice exams.

Thank-you for everyone's continued java support.

Respectfully,

TN - byte code for breakfast

funny picture linked but not uploaded to forum

[Helen Ma]

Why there is no deadlock?
In shove(), it synchronized(Stubborn.class).
In push(), it synchronized(Stubborn.class).

When the push () invoke the shove(), it actually execute like this:

   shove(){
         synchronized(Stubborn.class){



               synchronized(Stubborn.class) {

                         .....
                } //This block is replaced by the push() method
      }     
    }

Here you can see two syn block, whick locks the same object. For sure no deadlock.

Deadlock will occur if the code is like this:
Thread 1 executes the following code

      synchronized(objectA){
              synchronized (objectB){
                             ...
                }
     }   

Concurrently, thread 2 executes the following:

        synchronized(objectB){
              synchronized (objectA){
                             ...
                }
     }   
 

What goes wrong?
Possible steps:
1. Thread 1 locks objectA
2. Thread 2 locks objectB
3. Thread 1 waits for objectB
4. Thread 2 waits for objectA

You can see from step 3 and 4. Thread 1 is waiting for objectB, which may never be released by Thread2. Thread2 waits for objectA , which may never be released by Thread1.
Deadlock occurs.

[Ted North]

Thanks Helen. This makes sense. I appreciate your time and effort.

Regards,

Ted