VarHandles & LMAX Disruptor

Rezaei, Mohammad A. Mohammad.Rezaei at gs.com
Tue Jul 28 21:59:45 UTC 2015


Sorry if I wasn’t clear: I definitely agree on the explicit naming ; as for the naked ones, I’m slightly biased to keeping them.

Thanks
Moh

From: Michael Barker [mailto:mikeb01 at gmail.com]
Sent: Tuesday, July 28, 2015 5:54 PM
To: Rezaei, Mohammad A. [Tech]
Cc: valhalla-dev at openjdk.java.net
Subject: Re: VarHandles & LMAX Disruptor

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<mailto: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<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<mailto: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<mailto: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<mailto:paul.sandoz at oracle.com>>
>>> wrote:
>>>
>>>>
>>>> On 27 Jul 2015, at 23:04, Michael Barker <mikeb01 at gmail.com<mailto:mikeb01 at gmail.com>> wrote:
>>>>
>>>>> On 28 July 2015 at 02:32, Brian Goetz <brian.goetz at oracle.com<mailto: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



More information about the valhalla-dev mailing list