VarHandles & LMAX Disruptor

Kirk Pepperdine kirk.pepperdine at
Tue Jul 28 15:28:33 UTC 2015

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.


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

More information about the valhalla-dev mailing list