[jmm-dev] Specifying VarHandle acquire/release without ill effects

[Hans Boehm]

I disagree somewhat.  If you expect a variable will be used in a racy way,
then there's a fairly strong argument that programmers expect single
variable cache coherence, and you should try to provide it.  Especially if
it doesn't require special hardware instructions, which it doesn't on most
architectures.  Programmers just don't expect a counter that's only
modified by getting incremented by a single thread to decrease.

The situation is different if the variable is expected to be used in a
race-free way, where the cache coherence guarantee buys you nothing at some
performance cost. I think this is one of several reasons not to conflate
race-free accesses with unordered atomic accesses.

On Fri, Jun 24, 2016 at 5:21 PM, Martin Buchholz <martinrb at google.com>
wrote:

>
>
> On Thu, Jun 23, 2016 at 9:45 PM, Hans Boehm <boehm at acm.org> wrote:
>
>> There is another important difference between C++ relaxed atomics and
>> Java ordinary variables.  C++ relaxed atomics guarantee that accesses to a
>> single variable, independent of all other accesses, look sequentually
>> consistent.  I.e. we promise "cache coherence".  Java does not for ordinary
>> variables. And that's pretty critical for compiler optimization on the Java
>> side.  (It also affects fencing on one or two hardware platforms.)
>>
>
> Single variable cache coherence in C++ is unexpected and seems not in the
> spirit of C++.  I'm happy to keep that feature out of Java.
>
> But I'm still a fan of how acquire/release and fences are defined in C++
> (inspired by Java!) and hoping for some reciprocal inspiration.
>
>
>
>>
>> On Mon, Jun 20, 2016 at 10:48 AM, Martin Buchholz <martinrb at google.com>
>> wrote:
>>
>>> On Sat, Jun 18, 2016 at 4:50 AM, Doug Lea <dl at cs.oswego.edu> wrote:
>>>
>>> >
>>> > But we then discovered that doing this encountered some unsolved
>>> > research problems. Mainly that the current C/C++ model relies on rules
>>> > saying that programs with data races have no semantics ... Plus there
>>> are
>>> > a few
>>> > minor-mismatch snags that do not seem hard to address, including that
>>> > plain Java variables are a little stronger than plain C/CC variables
>>> > (for example references cannot be word-torn), but weaker than atomics
>>> > in relaxed mode (they are not required to be coherent).
>>> >
>>>
>>> My mental model is to map plain old java variables to C++ relaxed
>>> atomics,
>>> except for long and double, which could perhaps be mapped to an array of
>>> atomic bytes, technically eliminating all data races.  Both C++ and Java
>>> try to prevent OOTA results, and both succeed in practice, if not in
>>> theory.
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3710.html
>>>
>>
>>
>