RFR: 8181085: Race condition in method resolution may produce spurious NullPointerException

[Andrew Dinn]

On 26/05/17 10:40, David Holmes wrote:
> On 26/05/2017 7:35 PM, Andrew Dinn wrote:
>> Hi David,
>>
>> On 26/05/17 10:20, David Holmes wrote:
>>> Hi Andrew,
>>>
>>> On 26/05/2017 6:26 PM, Andrew Haley wrote:
>>>> On 26/05/17 03:20, David Holmes wrote:
>>>>> Any variable passed to an OrderAccess, or Atomic, function should be
>>>>> volatile to minimise the chances the C compiler will do something
>>>>> unexpected with it.
>>>>
>>>> That's not much more than paranoia, IMO.  If the barriers are strong
>>>> enough it'll be fine.  The problem was, I suppose, with old compilers
>>>> which didn't handle memory barriers properly, but we should be moving
>>>> towards standard ways of doing these things.  Standard atomics have
>>>> been available since C++11 (I think) and GCC has had support since long
>>>> before then.
>>>
>>> The issue isn't just the barriers that might be involved inside
>>> orderAccess methods. If these variables are being used in racy lock-free
>>> code then they should be marked volatile to ensure other compiler
>>> optimizations don't interfere. Perhaps that is paranoia, but I'd rather
>>> a little harmless paranoia than try to debug what might otherwise go
>>> wrong.
>>
>> I don't understand what you are suggesting here. How is such racy,
>> lock-free code ever going to work on architectures with weak memory
>> models?
> 
> By using load-acquire/store-release and atomic operations - that's how
> you write lock-free algorithms.

Now I'm even more confused. Surely, the implementations of
load-acquire/store-release and atomic operations themselves guarantee
that 'other compiler optimizations don't interfere'. Why doesn't that
make the volatile declarations redundant?

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander