[concurrency-interest] Relativity of guarantees provided by volatile

Boehm, Hans hans.boehm at hp.com
Mon Aug 20 14:46:35 EDT 2012


> From: Marko Topolnik
> 
> Yuval, rereading the earlier posts I noticed this one from you:
> 
> > That said, 17.4.3 does imply that the reads will be viewable in a
> wall-clock-sequential way, albeit informally
> >
> >     Sequential consistency is a very strong guarantee that is made
> about visibility and ordering in an execution of a program. Within a
> sequentially consistent execution, there is a total order over all
> individual actions (such as reads and writes) which is consistent with
> the order of the program, and each individual action is atomic and is
> immediately visible to every thread.
> >
> > (emphasis on "is immediately visible")
> 
> The major point to note is that the JLS **does not** enforce sequential
> consistency! It even spells it out directly below your quote:
> 
> "If we were to use sequential consistency as our memory model, many of
> the compiler and processor optimizations that we have discussed would
> be illegal."
> 
> The whole model of happens-before revolves around making sequentially
> INCONSISTENT executions APPEAR to be consistent, as observed by all
> executing threads, thus allowing all the optimizations that are
> discussed on this mailing list.
> 
It is intended to promise sequential consistency in the absence of data races. And the program Marko posted originally was data-race-free.  However, I don't believe there is a guarantee that the total ordering implied by sequential consistency is consistent with any means of retrieving the current time.  At least I haven't found such a claim.  Time retrieved on different processors may be out-of-sync, and has no implication on synchronization order.  That by itself can explain the behavior of the program that started this discussion.

If we changed the specification of currentTimeMillis() or the like so that it was guaranteed to access a volatile variable regularly updated by a "timer" thread, then the originally proposed behavior would no longer be allowed, since it would be compatible with any synchronization order for both the original and timer variables.  The problem is that timers don't appear to play by the same rules as variables.  Whether or not they should is unclear to me.

Hans



More information about the Concurrency-interest mailing list