[concurrency-interest] Relativity of guarantees provided by volatile
mtopolnik at inge-mark.hr
Tue Aug 21 04:12:27 EDT 2012
On 20. kol. 2012., at 23:20, Boehm, Hans wrote:
>> From: Marko Topolnik [mailto:mtopolnik at inge-mark.hr]
>> In the meantime I have read the JMM again very carefully. These are the
>> relevant conclusions:
>> Sequential consistency is an idealization that is not guaranteed in any
>> way. Real implementations virtually never produce sequentially
>> consistent executions.
> Sequential consistency is not normally defined to have anything to do with timing. Thus I don't understand the above statement.
JLS uses this phrase: "each individual action is atomic and is immediately visible to every thread." That "immediately" sounds timing-related, but on second reading this is not necessary: it just implies visibility to all the following actions in the execution order, and the execution order itself is still not required to be consistent with wall-clock time.
>> There is a guarantee that a properly synchronized program will APPEAR
>> to execute with sequential consistency. This appearance is, however,
>> limited only to the observed ordering of actions and nothing else. In
>> particular, no time ordering is guaranteed, promised, or even implied.
> Right. But time ordering is not really observable. Values returned by currentTimeMillis() and the like are observable, but the specification is, AFAICT, unclear about the extent to which those values have to reflect any kind of real "time ordering". I suspect that, at least on some machines, they use per-processors timers that are not perfectly synchronized.
Let's say that they could in theory be reflecting the exact time. We don't have to descend into the gory details of specific CPUs. Imagine a CPU specifically built to allow precise wall-clock time observation.
>> If you could remember any detail that would help me find this in the
>> archives, I would be very grateful. Just now I am composing another
>> question on StackOverflow that deals with this particular definition in
>> the JLS. I have already concluded beyond doubt that the wording is off,
>> however it is not at all clear how to fix it. The problem is with the
>> word "program" in that definition because a program is not the entity
>> that contains data races, it is its execution.
> I wasn't immediately able to find it with a mail search. I'll let you know if I do. Sorry. Unfortunately, I had a mail accident around January 2010, and it's hard for me to search earlier mail. It may also have been on the memory model list. Maybe someone else remembers?
In the meantime I was successful in my own search. It is indeed on the Memory Model list:
"a data race should be defined as conflicting actions on *non-volatile* variables
that are not ordered by happens-before".
Only with that addition is the loophole closed and even the original paper by Jeremy Manson and Bill Pugh doesn't close it. The need for the special case stems from the fact that volatile actions are asymmetric, as opposed to synchronized blocks, in terms of the pairing between acquire and release actions.
More information about the Concurrency-interest