File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Thread self test SCJP6 Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Thread self test SCJP6" Watch "Thread self test SCJP6" New topic
Author

Thread self test SCJP6

Dany Mariana
Greenhorn

Joined: Oct 31, 2009
Posts: 12
Hello,
After completing the test from Thread chapter, one question from it is not very clear to me.
This is the question:

15. Given:

And given these two fragments:
I. synchronized void chat(long id) {
II. void chat(long id) {


When fragment I or fragment II is inserted at line 5, which are true? (Choose all that apply.)

A. An exception is thrown at runtime
B. With fragment I, compilation fails
C. With fragment II, compilation fails
D. With fragment I, the output could be yo dude dude yo
E. With fragment I, the output could be dude dude yo yo
F. With fragment II, the output could be yo dude dude yo


Answer:
􀀂 ✓ F is correct. With fragment I, the chat method is synchronized, so the two threads can't
swap back and forth. With either fragment, the first output must be yo.
􀀂􀀁 A, B, C, D, and E are incorrect based on the above. (Objective 4.3)

I mark this question with both D and F and according with the explication this is right but here the good answer is only F.
I am wrong marking also the D and why?
Thank you
Dany Mariana
Greenhorn

Joined: Oct 31, 2009
Posts: 12
I understand that synchronized means that 2 threads can't access in the same time a method. This means they can go out a method before completed and reenter later to complete. Am I wrong?
Horia Constantin
Greenhorn

Joined: Sep 23, 2009
Posts: 22
Dany Mariana wrote:I understand that synchronized means that 2 threads can't access in the same time a method. This means they can go out a method before completed and reenter later to complete. Am I wrong?


LE: I have revised the initial explanation because it contained wrong informations
If you have a synchronized method and one thread enters it, no other threads can enter it (or alter the objects/classes that it involves) until the thread exists the method.(because the thread owns the lock for the object; no other threads will be able to enter any of the synchronized code that is referring to this object)

In your case, for synchronized void chat(long id) the first thread that enters the method finds the flag=0 (keep in mind that once it enters the method it will run until the for loop ends) and then the if is true so flag gets set with the id value so the if (flag==id) will return true every time (also you should keep in mind that both threads use the same object for invoking the synchronized method chat (d = new Dudes();) and d.chat) , therefore the output should be:

yo yo dude dude (this being the only possible alternative).

Cheers,
Horia


For every winner, there are dozens of losers. Chances are you're one of them.
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14432
    
  23

Dany Mariana wrote:Hello,
After completing the test from Thread chapter, one question from it is not very clear to me.

From which book is this, the SCJP Study Guide by Kathy Sierra and Bert Bates (also known as K&B)? Please mention the source when you copy a question, not everybody has the same book as you.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Ankit Garg
Sheriff

Joined: Aug 03, 2008
Posts: 9321
    
  17

Dany please Use Code Tags when you post a source code. You can edit your message using button and then add code tags to it...

SCJP 6 | SCWCD 5 | Javaranch SCJP FAQ | SCWCD Links
Dany Mariana
Greenhorn

Joined: Oct 31, 2009
Posts: 12
Yes, this is the book and for me is the only important book from which I can study to take the exam. That's why I didn't mention it.
Sorry

Jesper Young wrote:
Dany Mariana wrote:Hello,
After completing the test from Thread chapter, one question from it is not very clear to me.

From which book is this, the SCJP Study Guide by Kathy Sierra and Bert Bates (also known as K&B)? Please mention the source when you copy a question, not everybody has the same book as you.
Dany Mariana
Greenhorn

Joined: Oct 31, 2009
Posts: 12
Ok. I made a test :



Running different time this test i get the following result:
yo yo dude yo dude dude yo dude

If you are right the result should be: yo dude yo dude yo dude yo dude
Why the other result appear?
Please explain.

Horia Constantin wrote:
Dany Mariana wrote:I understand that synchronized means that 2 threads can't access in the same time a method. This means they can go out a method before completed and reenter later to complete. Am I wrong?


If you have a synchronized method and one thread enters it, no other threads can enter it (or alter the objects/classes that it involves) until the thread exists the method.
In your case, for synchronized void chat(long id) the first thread that enters the method finds the flag=0 (keep in mind that once it enters the method it will run until the for loop ends) and then the if is true so flag gets set with the id value so the if (flag==id) will return true every time, therefore the output should be:

yo yo dude dude (this being the only possible alternative).

Cheers,
Horia
Horia Constantin
Greenhorn

Joined: Sep 23, 2009
Posts: 22
I'm sorry for misinforming you in the beginning (apparently I was also misinformed). But it's clear to me now.
According to my revised explanation from above, this time you are using your threads with different objects (ch and new C()).
new Thread(ch).start(); gets the object lock for the ch object
new Thread(new C()).start(); gets the object lock for a new C object.
Soooo, different locks, unpredictable output.
If you were to write:
the output would be as you expected: yo dude yo dude yo dude yo dude

Hope I'm clear this time.

Cheers,
Horia

P.S.: Thanks for the opportunity you gave me to study the threads deeper.

The new code you wrote is quite different from what you had in the beginning.
In the first version (Dudes) you had a static long flag. When entering the synchronized method, the thread got the monitor lock for the class (aka because you have static the thread gets the lock for the class). And both threads in the example use the same class lock, that's why one of the threads must wait for the other one to finish.
Am I clear until now?

On the other hand, in your second example (TestThreadSyn) you designed a class with threads that get objects' lock (they are synchronized on the actual Threads objects, which are different; therefore the output is unpredictable).
Was I explicit enough?


Cheers,
Horia
Dany Mariana
Greenhorn

Joined: Oct 31, 2009
Posts: 12
Sorry but I think I don't understand. In the first example, the one from the book, the look is for object not for class. It is a method syncronized and the syncronized object is this no a static object of the class.

Horia Constantin wrote:Give me some time to make some tests as I seem to have been misled by your example and I think the explanation is different from the ones I gave you

The new code you wrote is quite different from what you had in the beginning.
In the first version (Dudes) you had a static long flag. When entering the synchronized method, the thread got the monitor lock for the class (aka because you have static the thread gets the lock for the class). And both threads in the example use the same class lock, that's why one of the threads must wait for the other one to finish.
Am I clear until now?

On the other hand, in your second example (TestThreadSyn) you designed a class with threads that get objects' lock (they are synchronized on the actual Threads objects, which are different; therefore the output is unpredictable).
Was I explicit enough?

Cheers,
Horia
Horia Constantin
Greenhorn

Joined: Sep 23, 2009
Posts: 22
Yes, I understand that now. Please see my revised answer in the posts above (I have edited them).

Dany Mariana wrote:Sorry but I think I don't understand. In the first example, the one from the book, the look is for object not for class. It is a method syncronized and the syncronized object is this no a static object of the class.

Horia Constantin wrote:Give me some time to make some tests as I seem to have been misled by your example and I think the explanation is different from the ones I gave you

The new code you wrote is quite different from what you had in the beginning.
In the first version (Dudes) you had a static long flag. When entering the synchronized method, the thread got the monitor lock for the class (aka because you have static the thread gets the lock for the class). And both threads in the example use the same class lock, that's why one of the threads must wait for the other one to finish.
Am I clear until now?

On the other hand, in your second example (TestThreadSyn) you designed a class with threads that get objects' lock (they are synchronized on the actual Threads objects, which are different; therefore the output is unpredictable).
Was I explicit enough?

Cheers,
Horia
Dany Mariana
Greenhorn

Joined: Oct 31, 2009
Posts: 12
Now is very clear, thank you very much.
I am glad that you study the threads deeper and you help me also to understand very well this chapter.

Horia Constantin wrote:I'm sorry for misinforming you in the beginning (apparently I was also misinformed). But it's clear to me now.
According to my revised explanation from above, this time you are using your threads with different objects (ch and new C()).
new Thread(ch).start(); gets the object lock for the ch object
new Thread(new C()).start(); gets the object lock for a new C object.
Soooo, different locks, unpredictable output.
If you were to write:
the output would be as you expected: yo dude yo dude yo dude yo dude

Hope I'm clear this time.

Cheers,
Horia

P.S.: Thanks for the opportunity you gave me to study the threads deeper.

The new code you wrote is quite different from what you had in the beginning.
In the first version (Dudes) you had a static long flag. When entering the synchronized method, the thread got the monitor lock for the class (aka because you have static the thread gets the lock for the class). And both threads in the example use the same class lock, that's why one of the threads must wait for the other one to finish.
Am I clear until now?

On the other hand, in your second example (TestThreadSyn) you designed a class with threads that get objects' lock (they are synchronized on the actual Threads objects, which are different; therefore the output is unpredictable).
Was I explicit enough?


Cheers,
Horia
Dany Mariana
Greenhorn

Joined: Oct 31, 2009
Posts: 12
It is a funny story regarding situation that we had.
A teacher tries hard to teach a child something but the child still doesn’t understand. Then the upset teacher says to the child: I explain you this till I get it myself but you still don’t understand!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Thread self test SCJP6