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

? Or do you intend > further constraints? > > Regards, > --Tobi > > > "valhalla-spec-experts" > wrote on 2019/12/18 08:46:42 PM: > >> From: John Rose >> To: valhalla-spec-experts >> Date: 2019/12/18 08:47 PM >> Subject: [EXTERNAL]

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

2019/12/18 08:47 PM > Subject: [EXTERNAL] atomicity for value types > Sent by: "valhalla-spec-experts" boun...@openjdk.java.net> > > In a nutshell, here’s a proposal for value type atomicity: > > - Define a contextual keyword “alwaysatomic" (working title “__AlwaysA

atomicity for value types

In a nutshell, here’s a proposal for value type atomicity: - Define a contextual keyword “alwaysatomic" (working title “__AlwaysAtomic”). - It can only occur with “inline” in class declaration. - All instances of the given inline class are protected against races. - Protection is “as if” each