Thread self test SCJP6

[Dany Mariana]

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

15. Given:

3. class Dudes {
4. static long flag = 0;
5. // insert code here
6. if(flag == 0) flag = id;
7. for(int x = 1; x < 3; x++) {
8. if(flag == id) System.out.print("yo ");
9. else System.out.print("dude ");
10. }
11. }
12. }
13. public class DudesChat implements Runnable {
14. static Dudes d;
15. public static void main(String[] args) {
16. new DudesChat().go();
17. }
18. void go() {
19. d = new Dudes();
20. new Thread(new DudesChat()).start();
21. new Thread(new DudesChat()).start();
22. }
23. public void run() {
24. d.chat(Thread.currentThread().getId());
25. }
26. }

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]

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]

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

[Jesper de Jong]

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.

[Ankit Garg]

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...

[Dany Mariana]

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]

Ok. I made a test :

import java.io.*;
public class TestThreadSyn implements Runnable {
	public void run() {
		move(Thread.currentThread().getId());
	 }
	synchronized void move(long id) {
		for(int i = 0; i <2;i++){
			System.out.print("yo ");
			System.out.print("dude ");
		}
	 }
	 public static void main(String[] args) {
		 TestThreadSyn ch = new TestThreadSyn();
		 new Thread(ch).start();
		 new Thread(new TestThreadSyn()).start();
	 }
}

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]

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:

  new Thread(ch).start();
new Thread(ch).start();  

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]

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]

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]

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:

  new Thread(ch).start();
new Thread(ch).start();  

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]

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!