[jmm-dev] State of play with modeling relaxed memory

[Doug Lea]

On 03/17/2014 01:39 PM, Alan Jeffrey wrote:
> This definition (together with the old one) seems to allow TC1 and TC8 but not
> TC9 or TC 18. It doesn't allow thin-air reads.

The listed rationale for TC 18 is probably the most debatable. For fun, try
cases 18a-c at http://www.saraswat.org/Test-variants.html

> Really you should be able to optimize (x=2; r3=x; P) to (x=2; r3=2; P),

I am surprised in retrospect that your approach gets so
far without such substitutions!

> This could probably be patched, but at the cost of extra complexity to the model.

This is a good opportunity to send out an attitude-adjustment rant I
once started writing:

We keep seeing examples where placing ordering constraints on accesses
(or understanding consequences of default ordering constraints) is
effective only if you have a full understanding of (potential)
compiler optimizations.  This meshes with my experience.  Sometimes
you need to write code in as close to its optimized form as possible
to be confident about ordering effects.  Otherwise, you can hit
situations where you feel like a doctor trying to perform brain
surgery while wearing oven mitts (and with the same chances of
success).

We are unlikely to see a sudden surge in popularity of pure parallel
dataflow languages in which you program via explicit order relations.
Short of these, even simple ordering constructions (in software and
hardware) phrased in terms of the "next" or "previous" access(es) can
lead to surprising transformations by optimizers and processors:
Perhaps there are multiple sources (e.g., due to aliasing) of a
value. Or the expected next access does not occur.  Or accesses occur
in unknown contexts across function calls or returns.  Or, on JVMs,
unexpected code is inserted in between the lines (dynamic type checks,
safepoints, etc). These phenomena all occur to varying degrees across
various kinds of ordering constraints (even SC) and across various
optimization rules.

So it seems inevitable that developing algorithms and code with
delicate ordering constraints will remain challenging.  But not much
more so than cases of aliasing, callbacks, etc in sequential code.
Core library and OS developers are drawn to these in efforts to
encapsulate all the tricky stuff. This works out OK so long as as the
tricky cases are not the common cases (which tends to be a
self-fulfilling property).

-Doug