About Question enthuware.ocpjp.v7.2.1453 :

[Wisevolk]

Hello,
could you explain something please, I choose False but for the following reason : k is a static variable so a class variable attached to the class. What it means, for me, Base has a variable k, Incrementor as a variable k and Decrementor as also a variable k.
I though because they aren't the same classes k was not the same and then the program because of k incrementor never terminate. But, while running the program I can see that k decrementor could start above 10.
So I could think "ok the classes share the same k" (even if it looks strange for me) but when k decrementor reach 0 it is never run again, and more k can be twice the same value within the same thread (two successive println of the same thread)
Thanks

[admin]

No, only Base has k. Incrementor and Decrementor do not have their own k. They can access Base's k.

So now that two threads are manipulating the same variable, it is possible that both the threads get to run one by one and one thread increments k and the other thread decrements k again and again.

HTH,
Paul.

[Wisevolk]

Thank's for your answer, so unless inherited classes shadow the base class variable, all classes have access to the base variable class by using their own class name and the bas class name ?

[admin]

Thank's for your answer, so unless inherited classes shadow the base class variable, all classes have access to the base variable class by using their own class name and the bas class name ?

That is correct.

[sumanenthu]

"the updates made by one thread may not be visible to another thread at all." - This line confused me. Both the threads are pointing to same static variable k. k is associated to class, not to the Incrementor or Decrementor object. So how can it be ThreadLocal?

One more thing what if the Decrementor thread gets to execute 10 times before the Incrementor even started. Then the k will be 0. Isn't that possible at all? Nothing is guaranteed in Threading.

[admin]

Where does the explanation say that k is ThreadLocal?
You have the quoted half of the explanation sentence. The complete sentence tells you the reason why the updates made by one thread may not be visible to another thread at all, "Since the variable k is not declared volatile, the updates made by one thread may not be visible to another thread at all."

For updates to a shared variable made by one thread to be visible to all the threads, either the threads must synchronize on a common lock or the variable must be volatile.

Here, the run methods are not synchronizing on a common lock before accessing the shared variable k. And k is not declared volatile either.

You need to go through a good book to understand this concept because this is important.

HTH,
Paul.

[sumanenthu]

Yes I understood your point that k is not declared as volatile. But what about 'static'? It means it is associated with an class not any object. So, in case of threading how can it be possible that one thread gets the value k = 5 and another gets the value k = 7?

[admin]

static only means that k is shared by all instances of the class. static has nothing to do with its value being correctly visible to multiple threads.
As I suggested to you above, your confusion arises because you have not read about how Java memory model works. You should consult a good book.
Here is a start: https://docs.oracle.com/javase/specs/jl ... ls-17.html
and
https://www.cs.umd.edu/~pugh/java/memor ... l#volatile

[sir_Anduin@yahoo.de]

If the update on k might not be visible to the other thread, then de decrementer could finish easyly. Then the incrementer will overflow k and go back to 0, and thereby terminate the loop.

so the only way it will run forever, is if the threads see the updates on k, right?

[sir_Anduin@yahoo.de]

am I wrong?

I think, I miss the concept of overflow here...

[admin]

The issue is not with overflow. You are right about that. The issue is with visibility of the variable. There is no guarantee whether it will be visible or not visible or when it will be visible. It is possible that some updates are visible and some are not. So you cannot rely on the fact that it will not be visible at all.

[sir_Anduin@yahoo.de]

thanks for your help. I scored 80% on the real exam today.

but still the question remains:lets asume that the incementer Thread sees only hin own changes to to the non volotile variable: eventually it must be canceled, because it will overflow and be less then 10.

[admin]

Yes, what you are saying is correct.
Congratulations on passing!

[Bhaskar]

I can just think of two cases where program will not terminate. First if the threads constantly switch from Incrementor and Decrementor and second if the changes made by one thread, specifically Decrementor to k is not seen by Incrementor because its non volatile. Also, if the question asked "The following program will sometimes terminate.", the answer would have been true. Please verify.

[admin]

Correct.