About Question enthuware.ocpjp.v7.2.1352 :

[shcher]

It seems to me that the option 4 is the correct answer due to possible memory consistency problems, though I was unable to reproduce memory consistency failure. "Java Concurrency in Practice" suggests defining such shared variables as "volatile".
Also see Double-checked Singleton and how it was broken in the earlier versions of Java:
http://javarevisited.blogspot.com/2014/ ... -java.html

Does anybody know why/why not memory consistency problems matter here?

[admin]

The two cases are different. You need volatile if you are reading a variable directly without using a synchronized block. Although volatile by itself will not prevent race condition, volatile will ensure that an updated value will be visible at some point in future.
In this question, all the access is happening from within synchronized blocks, so volatile is not required. But of course if you try to access x and y from outside a synchronized block, then you may not see updated values of x and y at all.

HTH,
Paul.

[nsobchuk]

Did I get it correct, that synchronized(this) locks the tc object and not the thread instance ( new Thread(tc) ) ?

[admin]

Yes, that is correct. When you do synchronized(xyz), you acquire the lock of the object pointed to by xyz. If you are not sure what is xyz pointing to, you can always do System.out.println(xyz) and confirm

[lawdog]

I argue that answer B) is incorrect because we cannot be certain that the first thread's modification to x and y will be visible to the second thread. I propose that a possible output could be:
"x = 1, y = 1"
"x = 1, y = 1" //This might be the case if the first thread to execute loops only once before the Thread manager decides to give time to the second thread.

This means that B) "It will keep printing values which show x and y always as equal and increasing by 1 at each line" is false due to violating "increasing by 1 at each line".

[admin]

I argue that answer B) is incorrect because we cannot be certain that the first thread's modification to x and y will be visible to the second thread.

Why do you think we cannot be certain that the first thread's modification to x and y will be visible to the second thread?

[lawdog]

I must have confused myself. As a read more about the memory model I realize that it is guaranteed that entering or leaving a synchronized block causes the updates to be available.

[krohani]

I also initially thought that one thread's modification of x and y may not be visible to the other thread, however upon further research I found this explanation on why that will never be the case. I think Paul also is saying the same thing in more simpler terms.

...synchronized keyword involves locking and unlocking. Before entering into synchronized method or block thread needs to acquire the lock, at this point it reads data from main memory rather than cache and when it release the lock, it flushes write operation into main memory which eliminates memory inconsistency errors.

Read more: http://javarevisited.blogspot.com/2011/ ... z3yxTsPJLS

[jagoneye]

The people who are confused about synchronization shows that you have not read the low level Locks properly. First read how those are used to lock and unlock then synchronized use will be clear as crystal.