volatile in java with long, int, boolean, and many different cases of write

Question

I have an exam coming up in a concurrent programming class. The class is fairly well structured, but I feel I must not understand the "volatile" keyword as well as I thought. I have read through other posts on how it works, and it seems to make sense, but my understanding of Java as a whole is limiting me. These are practice questions T/F, would anyone mind answering them and explaining why they are True or false? I have put my best guesses and explanations in

a. ____An int variable count is shared among several threads, where the only actions on count are to read its value, and to increment it. It suffices to mark count as volatile.

false, volatile keyword ensures that there are no local caches of this variable, but a race condition can still occur because the new value depends on the previous for count(and the operation is therefore not atomic), so two threads can read the value, increment it and there is still a race condition on write back. If count was not dependent on previous value (such as just an ID number that is written) this would work.

b. ____ The long variable count is shared among several threads, where the only actions on count it are to read its value, and to increment it. It suffices to mark count as volatile.

same as above, except even if the value is not dependent on previous values, this is not thread safe, since it is NEVER an atomic operation because long takes two write cycles for the upper and lower 32 bit writes and reads

c. ____ The boolean variable b, initially false, is shared between multiple threads. One specific thread sets its value to true, the other threads read the value. It suffices to mark b as volatile.

true, changing the boolean is atomic and can occur before an interrupt occurs, and updates for all other threads.

d. ____ The boolean variable b is shared between multiple threads. Any thread can set or read its value. Once b is set to true, it remains true henceforth. It suffices to mark b as volatile.

true, same reason as above.

Thanks so much!

Answer 1

a. your answer is fine (i.e. volatile is not enough)

b. "it is NEVER an atomic operation because long takes two write cycles for the upper and lower 32 bit writes and reads" => that is too strong for non volatile variables: non volatile long assignment may or may not be atomic. It is generally atomic on 64-bit processors but the Java Memory Model does not give any guarantees. However volatile long assignment is guaranteed to be atomic.

c. your answer is fine (although I don't understand what you mean by "before an interrupt occurs")

d. your answer is fine

Answer 2

Question D reminds me of why I hate T/F questions. It looks so similar to question C, and yet, if you changed it just a bit, it would be an entirely different, and interesting question:

e: Boolean var, initially false, Any thread may set it true, but it must only be set one time.

That is called the consensus problem: How do the threads choose which one among them gets to set the flag? In that case, volatile alone is not sufficient.

The consensus problem is fundamental to understanding multiprocessing. If you can't solve the consensus problem, then you can't have mutual exclusion, you can't have multiple consumer queues or multiple provider queues,... If you can't solve the consensus problem, then you really can't provide any correctness guarantees at all.

Did the author of question D have the consensus problem in mind? It's a tough call to make when you answer is limited to either T or F.