VarHandles & LMAX Disruptor

[Vitaly Davidovich]

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.

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.
>
>