[jmm-dev] bitwise RMW operators, specifically testAndSetBit/BTS

[Doug Lea]

Moving ever further away from the alleged subject line...


On 07/26/2016 01:09 PM, Paul E. McKenney wrote:
> On Mon, Jul 25, 2016 at 03:24:48PM -0400, Doug Lea wrote:
>> (Gratuitously editorializing, one would think that in C++,
>> it might also be popular to adopt this interpretation, and
>> eliminate the need to ever integrate C "volatile", or to
>> re-spec consume mode.)
>
> Yes and no.
>
> If I am working on a low-level synchronization primitive, then yes,
> I really do want the system to do -exactly- what I tell it to, no more,
> no less.
>
> But in higher-level code, I would likely be quite happy for the compiler
> to fuse accesses, if it could do so without violating the memory model.
>

The C++-relaxed spec definitely shows this tension. Sometimes people
want it to mean just "plain, but don't tear words".  Which is not the
same as what you'd otherwise spec as "the cheapest mode for a
thread-safe variable respecting coherence". In Java,
with the availability of "Plain" accesses even for volatiles,
and access-atomicity for references and <=32bit scalars,
there is little motivation to compromise for Opaque mode.

In which case, the main premise is that when users use non-plain
access modes for reads (similarly, but less interestingly writes), they
are expressing that they intend to handle all of the possible program
traces that might result if two subsequent reads see different values.
So implementations cannot be allowed to merge reads in ways that are
sure to reduce the number of possible program traces.

Again, this is symmetric to the idea that implementations cannot be
allowed to add writes (e.g., duplicate them) in ways that are sure to
increase the number of possible program traces.

It is surely possible to introduce a formalization of traces that
rigorously states both constraints. But it is not easy to define an
underlying trace model that covers practical execution issues. So in a
language spec, it may be preferable to just say no merged reads and no
added writes for atomics. Which is what C++ and Java both do now for
no-added-writes. Or, it may be a better idea to leave the trace-based
requirements incompletely formalized, which should have the same
practical effect. Or even better (but not soon) agree upon some formalism.

-Doug