RFR: 8181085: Race condition in method resolution may produce spurious NullPointerException
David Holmes
david.holmes at oracle.com
Fri May 26 09:40:40 UTC 2017
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.
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
>
More information about the jdk10-dev
mailing list