VarHandles & LMAX Disruptor

Rezaei, Mohammad A. Mohammad.Rezaei at
Tue Jul 28 16:03:29 UTC 2015

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.


>-----Original Message-----
>From: valhalla-dev [mailto:valhalla-dev-bounces at] On Behalf Of
>David M. Lloyd
>Sent: Tuesday, July 28, 2015 11:35 AM
>To: valhalla-dev at
>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> 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>
>>> wrote:
>>>> On 27 Jul 2015, at 23:04, Michael Barker <mikeb01 at> wrote:
>>>>> On 28 July 2015 at 02:32, Brian Goetz <brian.goetz at> 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

More information about the valhalla-dev mailing list