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

[Martin Buchholz]

In Java even plain variables default to atomic, so the cost of guaranteeing
special properties for atomics would be much higher than in C++ where
atomic<> will be rare.  Would it mean that plain fields can no longer be
cached in registers?

It is surprising to discover that relaxed atomics provide a kind of
sequential consistency, but restricted to a single memory location.  It may
be the right decision for C++.

On Sat, Jun 25, 2016 at 12:42 AM, Hans Boehm <boehm at acm.org> wrote:

> 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
>>>>
>>>
>>>
>>
>