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

Doug Lea dl at cs.oswego.edu
Thu Jul 21 12:53:07 UTC 2016


On 07/20/2016 07:17 PM, Hans Boehm wrote:
>     Can you simplify (*) to "r3 = r1" ? It depends on M:
>     * Java-Plain and C++-Plain: yes.
>     * Java Opaque: no.
>
> Does Opaque imply cache coherence?

Here, yes.

>     * C++-Relaxed: only if a != b.
>
>     * (And, for the record, other modes: no)
>
> What if the compiler knows that a==b? Can all the get()s be merged, even for Opaque?

Not in general unless thread-private (unescaped).

I hope to write up a summary of progress and open issues soon,
but in the mean time, here is the extremely telegraphic version
of my current thoughts:

Start with coherence, characterized in same way as current C++17 draft
(http://www.open-std.org/jtc1/sc22/wg21/). Like C++17, use sc-per-loc
as basis, here for for opaque, but (unlike C++ relaxed) constraining
read->write reorderings ("prescient" or "promised" writes), probably
based on in-progress work by mpi-sws group.  Distinguish Plain from
Opaque by weakening to sc-per-view (i.e., possibly-aliased access
paths). Disable merges for all modes except plain if there exist any
possible execution that could detect doing so (for example
disabling transforming a spin-loop into an "if"). Account for possible
mode weakenings for (unescaped) thread-private variables among other
cases. Add RA (release/acquire) and SC ("volatile") rules based on
work over the past year or so by Mark Batty, Viktor Vafeiadis, and
others (which also seem mostly present in C++17 draft). Also add other
fence and final field rules.

-Doug





More information about the jmm-dev mailing list