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

[David Holmes]

On 26/05/2017 7:48 PM, Andrew Dinn wrote:
> 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?

Good question. Perhaps with the right implementation it does. But for 
the last 15+ years as far as I am aware the general "wisdom" has been 
that use of C/C++ volatile was a necessary, but nowhere near sufficient, 
condition when writing such algorithms with 'hand-crafted' memory 
barriers and atomic instructions that are outside the C/C++ language, 
and the compiler.

Cheers,
David

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