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


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Another thread question" Watch "Another thread question" New topic
Author

Another thread question

Felix Tang
Greenhorn

Joined: Aug 15, 2006
Posts: 7
This is Q58 of the diagnostic exam:

class ThreadDemo {

private int count = 1;

public synchronized void doSomething()
{
for (int i = 0; i < 10; i++)
System.out.println(count++);
}

public static void main(String[] args)
{
ThreadDemo demo = new ThreadDemo();
Thread a1 = new A(demo);
Thread a2 = new A(demo);
a1.start();
a2.start();
}
}

class A extends Thread
{
ThreadDemo demo;
public A(ThreadDemo td)
{
demo = td;
}

public void run()
{
demo.doSomething();
}
}

A. It will print 0 to 19 sequentially.
B. It will print 1 to 20 sequentially.
C. It will print 1 to 20, but order cannot be determined.
D. It will print 0 to 19, but order cannot be determined.
E. The code will not compile.

If I'm not wrong, the answer should be B. What I want to ask is: wouldn't the synchronized method doSomething() give the same result if the method is NOT synchronized? (since both threads took the same reference of demo and share the instance for variable count)
Jon Lee
Ranch Hand

Joined: Mar 04, 2005
Posts: 134
yes, you are right......


SCJP 5.0 - 98% (2007)<br />SCWCD 1.4 - 97% (2007)
Jon Lee
Ranch Hand

Joined: Mar 04, 2005
Posts: 134
BTW, Felix. Where can I get this Felix diagnostic exam?? Is it free?
Neelesh Bodas
Ranch Hand

Joined: Jul 20, 2006
Posts: 107
Originally posted by Felix Tang:
[wouldn't the synchronized method doSomething() give the same result if the method is NOT synchronized? (since both threads took the same reference of demo and share the instance for variable count)


Yes, if the post-increment operation (count++) is atomic. And I don't think that such a thing is guaranteed. What happens if the scenario is following :

a) Thread-1 reads the count value as 6, stores it in the temp location (since it will need it later for returning) and now is just about to add one to the count...
b) and Thread-2 takes over, which reads the value of counter (6) , increments to 7, and returns the old value(6) which gets printed.
c) And then Thread-1 takes over again. It thinks that the value was 6, it increments it to 7 (again) and returns 6 (again!!)

Thats exactly where "synchronized" keyword comes in picture. When it comes to threads, very little is guaranteed. The java expressions (eg count++) are not necessarily atomic.
Felix Tang
Greenhorn

Joined: Aug 15, 2006
Posts: 7
Originally posted by Jon Lee:
BTW, Felix. Where can I get this Felix diagnostic exam?? Is it free?


This is from the Whizlab package. You can check from the FAQ. I downloaded the trial and it gives you about 15 Qs with explanations + free diagnostic test but no solutions.

thanks for the clarifications
amitesh kumar
Ranch Hand

Joined: Aug 01, 2006
Posts: 50
Hi,


In this code segment i added another ThreadDemo object and the result i am getting is weird.

The new code segment looks like



The output is sometimes 1 1 2 3 4 5 6 7 8 9 10 2 3 4 5 6 7 8 9 10
sometimes it is 1 1 2 2 3 4 5 6 7 8 9 10 3 4 5 6 7 8 9 10
and several such combinations.

Will someone eplain this strange behavior.
Amitesh
Surendra Kumar
Ranch Hand

Joined: Jul 04, 2006
Posts: 235
If you're creating a new ThreadDemo object, now you have two objects and two threads operating on these two different objects.
So two threads will have separate ThreadDemo locks.
The output will be based on which thread gets chance to run.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Another thread question