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

Martin Buchholz martinrb at google.com
Sat Jun 25 00:21:50 UTC 2016


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


More information about the jmm-dev mailing list