[cpp-threads] Yet another visibility question

[Doug Lea]

Boehm, Hans wrote:

> Con (a showstopper, I think): We don't know how to express
> dependency-based ordering in a way that's not broken by conventional
> optimizations on other compilation units that don't mention atomics, and
> remains usable of the store takes place on the far side of an
> abstraction boundary.
>


Of the use cases for raw operations, it seems that the most
defensible one is hand-crafted speculation. As in (for an atomic x)

int rawx = x.load_raw();
int nextx = f(rawx)
if (x.cas(rawx, nextx)) return;
// else maybe get a lock and do it the slow way

Since speculation is at the mercy of whatever happens,
you don't expect very much. But you do expect that the
load_raw actually reads x, and isn't completely
optimized away and replaced by say, 0.

So perhaps the place to start is to require that
raw loads and stores must at least actually occur
(unlike ordinary variables where dead ones can be killed).
Except that loads could be killed if it is provable that
across all executions of the program, the same value must
be read.

This sounds sorta like rules for old-style C volatiles?

You can probably go a little further by somehow saying
that the loads/stores must occur between any surrounding full
barriers that might exist. As in, not moving across
lock boundaries.

How much more do you need?

-Doug