Threads question (Resolved test question doubt)

Greetings there community

I am hell confuse with the following test question and its explanation, from Kathy's Sierra and Bert's Book (Chapter 9 - Threads, page 784 )

Which are true? (Choose all that apply.)
A. Compilation fails
B. The output could be 4 4 2 3
C. The output could be 4 4 2 2
D. The output could be 4 4 4 2
E. The output could be 2 2 4 4
F. An exception is thrown at runtime

Answer:
✓ F is correct. When run() is invoked, it is with a new instance of ChicksYack and c has
not been assigned to an object. If c were static, then because yack is synchronized, answers
C and E would have been correct.
A, B, C, D, and E are incorrect based on the above. (Objective 4.3)

:/

I see when run() is invoked, somehow takes instance of ChicksYack and , here the part I'm confuse with, it says c ... , why has not been assigned to an object? (What it does mean? ). (Isn't c instantiated already once thread invokes run()?)( Looks like it c weren't into the scope for run() but , no clue why )

Thanks in advance .

In your main method, what would be the output if there were just this code,

Hey hello there Praveen,

Praveen Kumar M K wrote:In your main method, what would be the output if there were just this code,

Hmm, that means chicksYack is trying to manipulate c object , but... wait.. if its inside main... its static method, so c should be static and initialized... is this the issue? then... hmm... no access.


EDIT: !oh! I do apologize, it seems this question were opened , found it through related topics -> https://coderanch.com/t/504261/java-programmer-SCJP/certification/non-static-object-as-lock (Yet a bit confuse all the explanation but I believe I get an idea thanks to your example Praveen (at least for me it's clearer than the whole thread there)).

David Samer wrote:Hey hello there Praveen,

Praveen Kumar M K wrote:In your main method, what would be the output if there were just this code,

Hmm, that means chicksYack is trying to manipulate c object , but... wait.. if its inside main... its static method, so c should be static and initialized... is this the issue? then... hmm... no access.

c need not be static and there is no access issue, however you are correct to point out that c should be initialized. We see that creating a new ChicksYack object does not inturn create a new Chicks object. Only a reference called c is created. Now, if we were to call the yack function on this reference, without initialization we would get a null pointer exception. Is that ok?

Now track back to the original program and see where a new Chicks object gets created and is assigned to "c". Let me know what you understand.

David Samer wrote:Greetings there community

I am hell confuse with the following test question and its explanation, from Kathy's Sierra and Bert's Book (Chapter 9 - Threads, page 784 )

Which are true? (Choose all that apply.)
A. Compilation fails
B. The output could be 4 4 2 3
C. The output could be 4 4 2 2
D. The output could be 4 4 4 2
E. The output could be 2 2 4 4
F. An exception is thrown at runtime

Answer:
✓ F is correct. When run() is invoked, it is with a new instance of ChicksYack and c has
not been assigned to an object. If c were static, then because yack is synchronized, answers
C and E would have been correct.
A, B, C, D, and E are incorrect based on the above. (Objective 4.3)

:/

I see when run() is invoked, somehow takes instance of ChicksYack and , here the part I'm confuse with, it says c ... , why has not been assigned to an object? (What it does mean? ). (Isn't c instantiated already once thread invokes run()?)( Looks like it c weren't into the scope for run() but , no clue why )

Thanks in advance .

It looks like c has been assigneed to an object, but that one belongs to the main thread. When it tries to run c.yack(Thread.currentThread().getId()), it needs a "c" which has been assigned to the new thread. In other words, "c" has not been initialized in the context. On the other hand, if c is static, it belongs to the class, not any individual instance, so we only need to instantiate it once.

Hope it answers your question.

Eric

Praveen Kumar M K wrote:

c need not be static and there is no access issue, however you are correct to point out that c should be initialized. We see that creating a new ChicksYack object does not inturn create a new Chicks object. Only a reference called c is created. Now, if we were to call the yack function on this reference, without initialization we would get a null pointer exception. Is that ok?

Got it!.

Praveen Kumar M K wrote:
Now track back to the original program and see where a new Chicks object gets created and is assigned to "c". Let me know what you understand.

As for what I see, tracking back, line 17 is the one in where Chicks object is created at the same time assigned to "c" . Fine, so far, but now it comes the confuse part for me. I suppose program keeps goinng so after line 17 , it creates another 2 object, but this time, both are Threads ,which both gets started but. In which point , can I know it will invoke run() and call yack(long id) method , as well as on which object?.

=================

Hey there Eric ;)

Praveen Kumar M K wrote:
It looks like c has been assigneed to an object, but that one belongs to the main thread. When it tries to run c.yack(Thread.currentThread().getId()), it needs a "c" which has been assigned to the new thread. In other words, "c" has not been initialized in the context. On the other hand, if c is static, it belongs to the class, not any individual instance, so we only need to instantiate it once.

Hope it answers your question

Wow!, I would say I'm a bit more confuse. I don't understand the part highlighted in black :/


=======

Thanks both for taking your time answering.

David Samer wrote:

As for what I see, tracking back, line 17 is the one in where Chicks object is created at the same time assigned to "c" . Fine, so far, but now it comes the confuse part for me. I suppose program keeps goinng so after line 17 , it creates another 2 object, but this time, both are Threads ,which both gets started but. In which point , can I know it will invoke run() and call yack(long id) method , as well as on which object?

Right, there are 2 new ChicksYack objects. But have we called the go method on these objects to initialize their internal Chicks objects? Nope, their "c" is still null.

Its a kind of catch-22 situation. If you actually did something like



you would have a recursive overflow..and without the call you would have a null pointer exception! A possible change would be as Zhenyi Luo suggested, to make c static.

Praveen Kumar M K wrote:

Right, there are 2 new ChicksYack objects. But have we called the go method on these objects to initialize their internal Chicks objects? Nope, their "c" is still null.

Its a kind of catch-22 situation. If you actually did something like



you would have a recursive overflow..and without the call you would have a null pointer exception! A possible change would be as Zhenyi Luo suggested, to make c static.

Oh! , that's the trick then. That was hell clear for understand it. It also has helped me out for understand Zhenyi's answer, reading it again a couple of times.

Thank you so much Praveen!

Can I take advantage for ask something else regarding question?

I copied code and paste it in my IDE. Then I did the needed change for get it working ( made c static and a new -> static Chicks c = new Chicks(); ) and what's my surprise the output is not what answer says but 9 9 10 10 instead. Is there any way we can know how to get these numbers? If someone else try its in their computer would get different numbers?

The thread "id" AFAIK is just some autogenerated number uniquely identifying a thread. I think if you run your program again maybe you'll get a different output.

Praveen Kumar M K wrote:The thread "id" AFAIK is just some autogenerated number uniquely identifying a thread. I think if you run your program again maybe you'll get a different output.

As I thought then. Thanks Praveen for all your help, it has been good and appreciated.

You are most welcome David! :-)