VarHandles & LMAX Disruptor

[Kirk Pepperdine]

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.

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