[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