aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Question about Thread Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Question about Thread" Watch "Question about Thread" New topic
Author

Question about Thread

dylan shen
Greenhorn

Joined: Oct 20, 2001
Posts: 10
class s implements Runnable{
int x=0,y=0;
synchronized void addX(){x++; }
synchronized void addY(){y++; }
void addXY(){x++;y++;}
boolean check() { return (x>y)? true:false
public void run()
{
////
System.out.println(check()); }
public static void main(String args[])
{ s run=new s();
Thread t1=new Thread(run);
Thread t2=new Thread(run);
t1.start();
t2.start();
}
}
If this methods are called in which order the check will return true?
Select all that apply
A.call addX() and addY() simultaneously for number of times in run()
B.call addY() and addX() simultaneously for number of times in run()
C.all addXY() for number of times in run()
What's the correct answer? Please explain why, thanks
R K Singh
Ranch Hand

Joined: Oct 15, 2001
Posts: 5370
hi dylan
I think in all cases, check() can return true.
because addX() and addY() are synchronized but run is not synchronized, hence it is very much possible that after calling addX() another thread starts execution and increment the x again and then check() will return true(This explanation is true for first two cases).
For third case as it(addXY()) is not synchronized so any thread can corrupt the data, and check() can return true.
CMIW
------------------
Regards
Ravish


"Thanks to Indian media who has over the period of time swiped out intellectual taste from mass Indian population." - Chetan Parekh
neha jain
Greenhorn

Joined: Oct 11, 2001
Posts: 27
hi guys,
don't u think the second option will make y greater than x.
so x>y will return false.
neha.
R K Singh
Ranch Hand

Joined: Oct 15, 2001
Posts: 5370
Hi Neha
I think u can not be sure ... as which thread will be running for how much time and when they will be swaped u do not know...
CMIW
Best think .... run this code and see the o/p.
but be sure to increase the buffer size of ur dos shell on win NT/2000... else u will see a part of o/p which can make u to think in wrong logic
------------------
Regards
Ravish
[This message has been edited by ravish kumar (edited October 25, 2001).]
HanMing Low
Ranch Hand

Joined: Oct 18, 2001
Posts: 196
Hi,
I think the answer is a and c.
Assuming,
a) the 1st thread is interrupted after addX() and 2nd completes addX() and addY() then check(). Then, x>y
c) similarly, if the thread is executed after x++ but before y++. Same thing happens.
but
b) as addY() is before addX(), there isn't a chance where y is increment before x. So, it's either same or less.
This is just my thinking.
Comments are welcome.
Cheers.

Han Ming
R K Singh
Ranch Hand

Joined: Oct 15, 2001
Posts: 5370
Yes ... I think you are right HanMing...
Sorry .... I must delete my above statemets...
THanks a lot HanMing
------------------
Regards
Ravish
Bruce Chapman
Greenhorn

Joined: Oct 25, 2001
Posts: 2
I think you guys hit the nail on the head if the
JVM is running the code *interpreted* ; however,
all bets are off once a highly optimizing JIT compiler
for a strange CPU architecture gets to this code.
You may not be able to see "true" returned for case
B on a given computer with a given JVM, but that
doesn't mean it cannot happen. Since the locks are
separate for the addX() and addY() methods, there is
no guarantee that you will always see x incremented
before y when looking at them with no locks. If you
used a common synchronization object and put { addX();
addY();} within a synchronized block of that object
AND had the check synchronize on the same object, then
and only then could you be sure B could never return
true.
There are a lot of issues around CPU store order
(total store order, partial store order, ...) that
can create a lot of unexpected behavior if you are
not very careful about locking things.
...Bruce
Originally posted by ravish kumar:
Yes ... I think you are right HanMing...
Sorry .... I must delete my above statemets...
THanks a lot HanMing

Ernest Lee
Ranch Hand

Joined: Aug 20, 2001
Posts: 145
i think if we change
"boolean check() { return (x>y)? true:false "
to
"boolean check() { return (x>=y)? true:false "
then...
Answer A & C will be correct.
However, if we didn't change the check() method,
x may equals y...
for example,
t1 called addX and addY
but t2 didn't call anything...
so.. x = 1 and y = 1.
,thus print false.
any comment?

Bruce Chapman
Greenhorn

Joined: Oct 25, 2001
Posts: 2
If you changed things as you mention, A,B, and C would
certainly also be correct, but they can be correct without
changing anything (just that the likelihood of them
resulting in check() returning true is lower).
The question is not well worded - it should probably
read "in which order *could* check return true. Check
will return once for each thread, and will *most likely*
return false for the second thread, as all incrementing
in both threads is then done so x should equal y.
Remember, there are two threads looping here (an indeterminate
number of times) - we know that one thread has finished it's
looping to call check, but we have no way of knowing where the
other thread is in it's progress when check() is called.
...Bruce
Originally posted by Ernest Lee:
i think if we change
"boolean check() { return (x>y)? true:false "
to
"boolean check() { return (x>=y)? true:false "
then...
Answer A & C will be correct.
However, if we didn't change the check() method,
x may equals y...
for example,
t1 called addX and addY
but t2 didn't call anything...
so.. x = 1 and y = 1.
,thus print false.
any comment?

Hades Pan
Ranch Hand

Joined: Nov 25, 2001
Posts: 106
I know the REAL ANS is B C bot don't why?
Uma Viswanathan
Ranch Hand

Joined: Jun 14, 2001
Posts: 126
Could i know which book or mock up exam contains this question?
I feel whatever call you add before
System.out.println(check()); in the run() method, we can not be certain of the output. We can not predict the execution behaviour of threads. So, the answer is none of the given answers.
So, please do provide me the link from where did you take this question?
Uma
Uma Viswanathan
Ranch Hand

Joined: Jun 14, 2001
Posts: 126
Valentin Crettaz and Jose Botella:
Could you guys provide your views regarding the thread concept?
I am thinking that at run time, we can not predict the execution behaviour of the thread (if we have more than one thread started), bcoz the thread scheduler decides which thread to run and for how long, the thread would run.
So, we cannot predict the output. Could we tell for any thread question, the answer as we can not be certain of the output?
Is the same answer true for the question in the forum http://www.javaranch.com/ubb/Forum24/HTML/012762.html
Your comments are welcome...please do guide me in a right direction?
Uma
http://www.javaranch.com/ubb/Forum24/HTML/012762.html
Valentin Crettaz
Gold Digger
Sheriff

Joined: Aug 26, 2001
Posts: 7610
Uma,
you are right, the output of threads is not predictable since it depends on the underlying platform. But if there are some methods in the code (like join) that hint about how the threads' behavior is shaped then sometimes you might deduce the correct output sequence...
There are some questions on that in some mock exams, but I don't remember exactly which ones...

------------------
Valentin Crettaz
Sun Certified Programmer for Java 2 Platform


SCJP 5, SCJD, SCBCD, SCWCD, SCDJWS, IBM XML
[Blog] [Blogroll] [My Reviews] My Linked In
Uma Viswanathan
Ranch Hand

Joined: Jun 14, 2001
Posts: 126
Thanks Valentin. When i think seriously about taking SCJP2 exam and prepare mockup exams (i hope that surely one day), i will catch you regarding that join(), when i come across.
Uma
Jose Botella
Ranch Hand

Joined: Jul 03, 2001
Posts: 2120
Hello everybody
This question is not well worded. Also it is not very useful to show the key points about threads.
Though we can not predict the order of execution of a thread, we can believe for certain the following:
a)The order in which a thread executes its instructions is sequential. Bruce has pointed out one spoiler the optimized compilers could rearrange the order of bytecodes. Also there is problem with the cache synchronization in multiprocessor systems. I don't know to what extends this could impact the secuential execution. It must not to be a great one because the programmer should rely on the execution it intended for a program. (Unless proper synchronization was needed on those systems)
b)The regions of code that are guarded by the same monitor can not be executed concurrently. They will be executed in a secuential way.
If I have figured out well what the question is, it ends up in adding calls to addX, addY and addXY within run:
Supposing only line 5 is not commented out. The only chance for check to print true is that the call to check took place after the execution of x++ but before y++ by the other thread. This is possible because addXY is not synchronized. Being the two treads selfish one (no yielding or sleeping but running as much as the scheduler permits them) the scheduler has a hard work for "scheduling" them so it is very difficult to execute one thread bettween x++ and y++ of the other. I haven't seen true in the output for this execution. But it can not be discarded.
Supposing only line 1 and 4 are not commented out. It happens the same as above. Because is difficult to schedule a thread between the calls addX and addY I haven't seen true in the output. However now make lines 2 and 3 executable. You will see true in the output because there is enough time for a thread to call check between addX and addY of the other.
Supposing only line 1 and 4 are not commented out. But interchange the positions of addX and addY. Besides that make lines 2 and 3 excutable. You would never see true printed unless in the JVM implementation a kind of compiler optimization would alter the order of bytecodes. I haven't seen true whatever lapse I set for sleep.
I hope it helps though I have't added anything new.


SCJP2. Please Indent your code using UBB Code
Uma Viswanathan
Ranch Hand

Joined: Jun 14, 2001
Posts: 126
Do you mean for these kind of questions, we can not simply say that the order of execution is not predictable...?
A good explanation...and a lot of work to explain the fact...thanks Jose...
So, the answers for that question are
A. call addX() and addY() simultaneously for number of times in run() and
C. all addXY() for number of times in run()
Even though the possibility of the scheduler to call check() in between (after x++ and before y++) is very less, occasinally we may get true. Right?
Once again thanks Jose...
Uma
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Question about Thread
 
Similar Threads
about Thread
another question about thread?
help me!
The use of synchronized and cheak()
Thread problem.