VarHandles & LMAX Disruptor

[Vitaly Davidovich]

Is that in scope though given that VarHandles are really meant to replace
Unsafe usage, and I don't see how Unsafe supports that "naked"/default
aspect today.

On Tue, Jul 28, 2015 at 5:59 PM, Rezaei, Mohammad A. <Mohammad.Rezaei at gs.com
> wrote:

> Sorry if I wasn’t clear: I definitely agree on the explicit naming ; as
> for the naked ones, I’m slightly biased to keeping them.
>
> Thanks
> Moh
>
> From: Michael Barker [mailto:mikeb01 at gmail.com]
> Sent: Tuesday, July 28, 2015 5:54 PM
> To: Rezaei, Mohammad A. [Tech]
> Cc: valhalla-dev at openjdk.java.net
> Subject: Re: VarHandles & LMAX Disruptor
>
> I definitely want all of the explicitly named accessor methods, as the the
> "naked" get/set with the defaulting behaviour I'm indifferent.
>
> Mike.
>
> On 29 July 2015 at 04:03, Rezaei, Mohammad A. <Mohammad.Rezaei at gs.com
> <mailto:Mohammad.Rezaei at gs.com>> wrote:
> I had the same reaction when I first read this, especially because if I
> wanted to read/assign using the declared default, I'd just use the plain
> variable. However, there may be use cases outside of concurrency that
> warrant the "naked" methods, namely as a replacement for reflective Field
> access in frameworks that need to do that sort of thing.
>
> Just my $0.02.
>
> Thanks
> Moh
>
> >-----Original Message-----
> >From: valhalla-dev [mailto:valhalla-dev-bounces at openjdk.java.net<mailto:
> valhalla-dev-bounces at openjdk.java.net>] On Behalf Of
> >David M. Lloyd
> >Sent: Tuesday, July 28, 2015 11:35 AM
> >To: valhalla-dev at openjdk.java.net<mailto:valhalla-dev at openjdk.java.net>
> >Subject: Re: VarHandles & LMAX Disruptor
> >
> >On 07/28/2015 10:28 AM, Kirk Pepperdine wrote:
> >>
> >> On Jul 28, 2015, at 4:56 PM, Vitaly Davidovich <vitalyd at gmail.com
> <mailto:vitalyd at gmail.com>> wrote:
> >>
> >>> I'll second Mike's suggestion of having VarHandle method names reflect
> >>> their memory ordering effects, although I don't know if I'd want
> get/set to
> >>> use the default based on the presence/absence of volatile modifier.
> If the
> >>> API were to expose all supported flavors of ordering, it'd be nice if
> *all*
> >>> read/write ops had the effect in the method name.
> >>
> >> Absolutely, it will have a tremendous positive impact on the
> readability of
> >the code.
> >
> >I agree - VarHandles by nature represent a move away from having "kinds"
> >of variables towards instead having "kinds" of access.  No need to muddy
> >those waters with a needless default (under what circumstances would
> >that be useful I wonder?).
> >
> >>
> >> Regards,
> >> Kirk
> >>
> >>>
> >>> On Tue, Jul 28, 2015 at 10:24 AM, Paul Sandoz <paul.sandoz at oracle.com
> <mailto:paul.sandoz at oracle.com>>
> >>> wrote:
> >>>
> >>>>
> >>>> On 27 Jul 2015, at 23:04, Michael Barker <mikeb01 at gmail.com<mailto:
> mikeb01 at gmail.com>> wrote:
> >>>>
> >>>>> On 28 July 2015 at 02:32, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
> >>>>>
> >>>>>>        - I think VarHandle.set/get should be called
> >>>>>>>        setRelaxed/getRelaxed as
> >>>>>>>        it> would make it more obvious to a user and a reader what
> those
> >>>>>>>        methods are> going to do.  My initial assumption was that
> they
> >>>>>>> were
> >>>>>>>        no different from a> normal write/read of a field.
> >>>>>>>
> >>>>>>>    An alternative here is that get/set does whatever the default
> is for
> >>>>>>>    that field (so a volatile field would get ordered access) and
> >>>>>>>    {get,set}Relaxed would force a relaxed access (even for volatile
> >>>>>>>    fields.)
> >>>>>>>
> >>>>>>> That would make sense, however it would preclude the ability to
> apply a
> >>>>>>> normal load/store to volatile field.
> >>>>>>>
> >>>>>>
> >>>>>> Sorry, I wasn't clear.  "Alternative" applied to "get rid of
> get/set"
> >>>>>> within the context of having an explicit {set,get}Relaxed.  In other
> >>>> words,
> >>>>>> have getters/setters for all the modes, and then define "naked"
> get/set
> >>>> to
> >>>>>> mean "whatever is default for this variable.
> >>>>>>
> >>>>>
> >>>>> If VarHandles supported all access modes (Volatile, Acq/Rel, Relaxed
> and
> >>>>> Normal) with explicit calls and provided "naked" get/set as a default
> >>>> based
> >>>>> on the absence/presence of the volatile modifier then that would make
> >>>> for a
> >>>>> nice, complete API.
> >>>>>
> >>>>
> >>>> I think that’s a good suggestion, worth adding. Stay tuned.
> >>>>
> >>>> Paul.
> >>>>
> >>>>
> >>
> >
> >--
> >- DML
>
>