> The only special atomicity properties of volatile I’m
> appealing to are those which apply to long and double.
Thanks for confirming that.
> In effect, if an inline object contains a pointer,
> storing it should include a previous store-store ordering
> constraint, or some other implementation
On 1/13/20 4:44 PM, Tobi Ajila wrote:
> Hi John
>
> Given that inline types can be flattened there is a possibility that
> data races will occur in places where users were not expecting it
> before. So your `__AlwaysAtomic` modifier is a necessary tool as the
> existing spec will only enforce atom
On Jan 14, 2020, at 9:11 AM, Doug Lea wrote:
>
> On 1/13/20 4:44 PM, Tobi Ajila wrote:
>> Hi John
>>
>> Given that inline types can be flattened there is a possibility that
>> data races will occur in places where users were not expecting it
>> before. So your `__AlwaysAtomic` modifier is a nece
On Dec 18, 2019, at 5:46 PM, John Rose wrote:
>
> - Define a contextual keyword “alwaysatomic" (working title “__AlwaysAtomic”).
I just referred more carefully to the draft JEP on keyword
management https://openjdk.java.net/jeps/8223002 and
realize that it guides us toward a so-called “hyphenate
In the context of Java, we are already using the term 'atomic', in
AtomicInteger, AtomicLong, etc,
and in that case the semantics is volatile + atomic operations (at least CAS),
so i think using atomic or any keyword derived from it will not help to our
users to understand the semantics for an
On Jan 14, 2020, at 4:52 PM, Remi Forax wrote:
>
> In the context of Java, we are already using the term 'atomic', in
> AtomicInteger, AtomicLong, etc,
Even more fundamentally, the term “atomic” is in the JLS, JVMS, and JMM
with the same meaning being proposed here, and *not* subsumed by nor id
