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

JQ plus thread question  RSS feed

 
sajida kal
Ranch Hand
Posts: 89
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Question ID :971037111660
public class TestClass implements Runnable
{
int x = 0, y = 0;
public void run()
{
while(true)
{
synchronized(this)
{
x++; y++;
System.out.println(" x = "+x+" , y = "+y);
}
}
}
public static void main(String[] args)
{
TestClass tc = new TestClass();
new Thread(tc).start();
new Thread(tc).start();
}
}
options given are -
1.It will throw exception at runtime as two threads cannot be created at the same time.
2.It will keep on printing values which show x and y as always equal and increasing by 1 at each line.
3.It will keep on printing values which show x and y as different.
4.Nothing can be said abt the sequence
5.It will keep on printing which show x and y as always equal but may increase more than one at each line.

Answer is 2 acc to JQplus. Reason: Here, the access to shared variables x and y is in syncronized block so when any thread gets access to the block it increments both x and y before the other thread can touch the block. This makes sure that the values of x and y are always same and they increase one by one.
I agree with the above line of reasoning and had worked out the same logic till this point. But the phrasing of answer has has missed out one aspect. The answer seems to imply that the output will be printed for each thread as if one thread is executing one after the other cleanly. But the JVM could always switch between the execution of the threads, due to its time slicing, such that the output would look like this
x=0,y=0 (for thread 1)
x=1,y=1 (for thread 1)
x=0,y=0 (for thread 2)
x=2,y=2(fpr thread 2) and so on.
So option 2 which assumes that the values of x and y increase by one on each line seems incorrect.(in the above example, the output on the line is not necessarily from the same thread and it is not increasing consistently from one line to the next).
So this is why I chose option 4. If option 2 is rephrased such that it specifies that the x and y for a given thread increase by 1 and the words 'on each line' are removed, then it would be correct.
I am hoping for ranch members comments on this. Paul, could also give your opinion on this ?
Thanks everyone!
Sajida
 
Paul Anilprem
Enthuware Software Support
Ranch Hand
Posts: 4097
33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with you. The phrase "on each line" should not be there and the wording should be improved.
thanks for the feedback,
Paul.
------------------
Get Certified, Guaranteed!
(Now Revised for the new Pattern)
www.enthuware.com/jqplus

Your guide to SCJD exam!
www.enthuware.com/jdevplus
Try out the world's only WebCompiler!
www.jdiscuss.com
 
Paul Anilprem
Enthuware Software Support
Ranch Hand
Posts: 4097
33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry, I do not agree with you. You can never have an output like:
x=0,y=0 (for thread 1) //line 1
x=1,y=1 (for thread 1) //line 2
x=0,y=0 (for thread 2) //line 3
x=2,y=2(fpr thread 2) and so on
No matter in what order the threads are scheduled.
Once a thread enters the synch. block it comes out only after incrementing x and y. And even if this thread gets preempted the other thread cannot enter the synch. block. So again the first thread runs. Now, if a thread has printed some values or x and y ( say 0, 0) there is no way this thread or any other thread can print the same values ( 0, 0) again. And which ever threads runs next it will print the values that are incremented by 1.
So, the given option and answer both correctly describe the behaviour.
-Paul.
------------------
Get Certified, Guaranteed!
(Now Revised for the new Pattern)
www.enthuware.com/jqplus

Your guide to SCJD exam!
www.enthuware.com/jdevplus
Try out the world's only WebCompiler!
www.jdiscuss.com
 
sona gold
Ranch Hand
Posts: 234
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i agree with u paul
even in the case of time slicing
if a thread enters a synchronized block it has to execute for that period of time printing the specified values for that period

 
sajida kal
Ranch Hand
Posts: 89
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Paul,
You are absolutely right. The case I described would hold true
if the instance of class TestClass passed to the two threads were different. Its the same instance here, so option 2 is correct. A great question, like the rest of the software
now i also know that giving a test when one is on the verge of sleep is a bad idea.
I also noticed one thing, the synchronized block has no wait statement or notify statement, so the first thread that is executed by JVM, gets the lock and executes infinitely. The values being printed are of course always greater than the preceding lines. This means that even if I remove the second
new Thread(tc).start() statement, the question and the answer still hold !
Cheers
Sajida
 
Scott Appleton
Ranch Hand
Posts: 195
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I also noticed one thing, the synchronized block has no wait statement or notify statement, so the first thread that is executed
by JVM, gets the lock and executes infinitely. The values being printed are of course always greater than the preceding lines.
This means that even if I remove the second
new Thread(tc).start() statement, the question and the answer still hold !

Sajida, initially I thought the same thing -- that the second thread was extraneous and would never execute the synchronized block because of the infinite while(true) block. However, I reconsidered when I noted that the synchronized block of code is within the while block.
I figured that the first thread enters the while block, gets a lock when it enters the synchronized block, processes, then gives up the lock upon exiting the synchronized block. Then it iterates the while block again, gets the lock again, etc.
This leaves open the possibility that preemptive timeslicing will at some point give the processor to the second thread at a point in time when the first thread is outside of the synchronized block. If so, the lock is available and the second thread can take it.
 
sajida kal
Ranch Hand
Posts: 89
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Scott,
Thanks for pointing that out. 'Polite' threads use some flags to indicate that other threads can access objects which are accessed through synchronized methods. But its not a must. This concept is now clear , thanks a lot,
Cheers,
Sajida
 
Farhan Tariq
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi ranchers!!
Ifigured out the problem. I change the program as:
public class TestClass implements Runnable
{
int x = 0, y = 0;
public void run()
{
while(true)
{
synchronized(this)
{
x++; y++;
System.out.println(" x = "+x+" , y = "+y+"\t"+Thread.currentThread().getName());
}
}
}
public static void main(String[] args)
{
TestClass tc = new TestClass();
new Thread(tc).start();
new Thread(tc).start();
}
}
so it prints thread0, thread1 also. So i think Scott is 100% right. If u have any confusion just check that code.
And remind it option no 2 is correct because x and y increases by one in every line.

[This message has been edited by Farhan Tariq (edited May 25, 2001).]
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!