VarHandles & LMAX Disruptor

[Michael Barker]

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>
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] On
> Behalf Of
> >David M. Lloyd
> >Sent: Tuesday, July 28, 2015 11:35 AM
> >To: 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>
> 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>
> >>> wrote:
> >>>
> >>>>
> >>>> On 27 Jul 2015, at 23:04, Michael Barker <mikeb01 at gmail.com> wrote:
> >>>>
> >>>>> On 28 July 2015 at 02:32, Brian Goetz <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
>