Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

How can I get "true" from this code?  RSS feed

 
Woo Hwang
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I found this code snippet from one of my favorite SCJP study sites.
class synchtest {
private int x;
private int y;
public void setX(int i){
x=i;
}
public void setY(int i){
y=i;
}
public synchronized SetXY(int i){
setX(i);
setY(i):
}
public synchronized boolean check(){
return x!=y;}
}

The question is what make the check() return true supposing we access this class by mutiple thread, and the answer was check() never return true, and I aggreed to that.
But another possible answer which I doubted was that the check() might have returned true if x,y could have been set seperately. What I doubted here was if I have editted code to set x,y seperately, I would have made out thread code snippet like this :
thread 1:
synchtest s1=new synchtest();
s1.setX(1);
s1.setY(1);
System.out.println(s1.check());
thread2:
synchtest s2=new synchtest();
s2.setX(2);
s2.setY(2);
System.out.println(s2.check());
and the reason I disagreed with possible true proposition was that if thread1 and thread2 have different value set on x,y , the possible situation that check() returns true is:
1. thread1 (Let's assume that thread1 starts first) sets x to 1.
2. thread1 stops executing because thread2 starts runnig with dominated priority.
3. thread2 sets x to 2 and on the way to setting y to 2, thread2 stops execution because thread1 gets previlege to continue its process, so y is set to 1 also, thread1 is not intervened by thread2, and successfully performs check() method.
In this case, check() returns true, I thought.
But in a real situation, thread doesn't go like that so far as I know. It's like thread 1 operates all the way to the end, then thread2 does same as thread1. When I ran that code with do/while block embracing those processes above , it never did like the preposition above.
Then I put sleep(2000) in between each code setting x and y value except SetY() in thread1 with assumption that if thread1 sets x and goes on sleeping then thread2 takes chance to setX to 2 and goes on sleep and thread1 continues its process to set y to 1 but no sleep. It continues to process to call check() method. Therfore, x=2, y=1 which check() returns true.
thread 1:
synchtest s1=new synchtest();
s1.setX(1);
sleep(2000);
s1.setY(1);
System.out.println(s1.check());
thread2:
synchtest s2=new synchtest();
s2.setX(2);
sleep(2000);
s2.setY(2);
sleep(2000);
System.out.println(s2.check());
But my assumption was wrong. What I found out from running this code was that ,yes, thread ran like this:
Run thread1 and set x=1 --> thread1 sleeps---> thread2 starts to run and set x=2 --->thread2 sleeps --->thread1 resumes and set y=1----> no sleep in thread1 and call check()
As you can see before calling check, value x,y are 2,1, different !! So check() should return true. But it didn't return true. I wonder why. So I put some tracers to check values of x,y . What I saw was that x,y in thread1 were independent on x,y in thread2. I mean, each thread has its own x,y values and what happened in a real situation was different from my assumption. The REAL situation is :
Run thread1 and set x=1 --> thread1 sleeps---> thread2 starts to run and set x=2 --->thread2 sleeps --->thread1 resumes and set y=1----> no sleep in thread1.Call check()---> returns false because x,y values in thread1 are 1,1 not 2,1. x,y values in Thread2 are 2,2
Why two thread have thier own value? is that a result of race condition that people warn of





[This message has been edited by Woo Hwang (edited August 11, 2001).]
 
Girish Pednekar
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thread1 and thread2 are referring to 2 different instances of synchtest. since x and y are instance variables, s1 and s2 each have their own copy of x and y. try changing x and y to static.
thanks,
GP
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!