RFR: 8305819: LogConfigurationTest intermittently fails on AArch64

[Xin Liu]

On Fri, 5 May 2023 13:10:15 GMT, Dan Gao <duke at openjdk.org> wrote:

>> I've had an idea. How about you use a load-acquire on the reader side, making the code correct, with a FIXME comment. Something like "// FIXME: memory_order_consume could be used here."
>> Then, I will add memory_order_consume to the shared atomic code, which we can define appropriately in the OS/CPU section. OK?
>
>> I've had an idea. How about you use a load-acquire on the reader side, making the code correct, with a FIXME comment. Something like "// FIXME: memory_order_consume could be used here." Then, I will add memory_order_consume to the shared atomic code, which we can define appropriately in the OS/CPU section. OK?
> 
> That's OK.

@gaogao-mem 

> There is a data race between the writer and reader(s). The writer step (3) and (4) modify the _level_start array and _next of a old node, and the reader step (1) reads from _level_start and _next of a node. This causes a UB. And in current problem, the reader step (2) may read an incorrect _value from a new node.

This is UB, but the reason isn't the data race. In RCU technique, a load of aligned pointer is either old or new. With a storestore barrier, a reader is supposed to see the new memory state if it has seen the new pointer.  

It's UB because compiler optimizations may flip over in load node->_value before the program evaluate _level_start[level]. In your diagram, it's something like this. 


The Reader(s)

| (0) reg <= (node->_value)
| (1) traverse all nodes from _level_start[level]
| (2) call *reg->write()
|

In my understanding, no compiler can conduct an optimization like that because evaluation of 'node->value' prematurely may have side-effect(segfault). it's legal indeed. 

@theRealAph 
I read up the C++ standard about release-consume order. Sorry, I didn't realize that it has been standardized. Given that, we better off conforming to the C++ rules instead cheating. 

I'm also okay that your load-acquire solution.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13421#issuecomment-1536618741