[concurrency-interest] Relativity of guarantees provided by volatile
hans.boehm at hp.com
Mon Aug 20 17:20:24 EDT 2012
> 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.
> 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.
> > 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.
> It would be very bad for performance if they played by those rules, I
> think. In particular, a volatile var involves two distinct concepts:
> - a hard guarantee of proper happens-before ordering of actions on it;
> - a soft **promise** of timely publishing of write actions.
> So the volatile concept is by its nature much more about ordering than
> about timing.
Maybe. Having a thread in the kernel update the time values and having it play by Java volatile rules when writing the time value actually doesn't sound that expensive for a low resolution timer. You will probably get a cache miss on the timer location from every core after every update, so it is likely to be a problem for high resolution timers or very high core counts.
> >> This a very nice catch. Isn't in fact any read in a data race with
> >> writes by another thread following the write it observed? That would
> >> make it impossible to write a program free of data races. In other
> >> words this sounds like a loophole in the definition of a data race.
> > That's a bug in the wording of the spec. I have a vague recollection
> that it was pointed out before a couple of years ago, possibly even on
> this list. It's one of these things that should really be fixed, but
> is waiting for a resolution of the harder Java memory model issues.
> 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?
More information about the Concurrency-interest