Re: atomicity for value types

- Mail original - > De: "John Rose" > À: "Remi Forax" > Cc: "valhalla-spec-experts" > Envoyé: Mercredi 15 Janvier 2020 02:18:07 > Objet: Re: atomicity for value types > On Jan 14, 2020, at 4:52 PM, Remi Forax wrote: >> >> I

Re: atomicity for value types

I've always felt that it's better to have concurrency properties declared as part of the type, guided by C++ atomic<>, and VarHandle was a step away from that (towards concurrency "assembly language"). It's more difficult in Java where there are no zero-cost user abstractions (yet!). I'm worried

Re: atomicity for value types

On 1/14/20 3:43 PM, John Rose wrote: > On Jan 14, 2020, at 9:11 AM, Doug Lea > wrote: >> In which case "__AlwaysOpaque" would be a more accurate term. > > Very interesting!  I guess this is the most relevant definition of opaque: >  

Re: atomicity for value types

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

Re: atomicity for value types

c-experts" > Envoyé: Mercredi 15 Janvier 2020 01:40:34 > Objet: Re: atomicity for value types > On Dec 18, 2019, at 5:46 PM, John Rose < [ mailto:john.r.r...@oracle.com | > john.r.r...@oracle.com ] > wrote: >> - Define a contextual keyword “alwaysatomic" (working

Re: atomicity for value types

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

Re: atomicity for value types

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

Re: atomicity for value types

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

Re: atomicity for value types

y to the withfield bytecode? --Tobi > From: John Rose > To: Tobi Ajila > Cc: valhalla-spec-experts > Date: 2020/01/13 05:03 PM > Subject: [EXTERNAL] Re: atomicity for value types > > On Jan 13, 2020, at 1:44 PM, Tobi Ajila wrote: > > > > Hi Jo

Re: atomicity for value types

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 atomicity for 32bit primitives and references. I just