RFR: 8305819: LogConfigurationTest intermittently fails on AArch64

Xin Liu xliu at openjdk.org
Mon May 8 17:03:35 UTC 2023


On Sat, 6 May 2023 09:37:13 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Hi, is the current solution okay with you? @dholmes-ora
>
>> @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.
> 
> I disagree. The data race  _is_ the reason. A compiler is allowed to move loads because a data race is UB.
> 
>> It's UB because compiler optimizations may...
> 
> ...do absolutely anything. Once you have undefined behaviour, the entire program is undefined.
> The C++ standard doesn't deal with compilers or optimizations, When a program is undefined, it is undefined whatever a compiler does. 
> 
> It's  not possible to negotiate with a compiler around UB.
> 
> @gaogao-mem  is correct.

hi, @theRealAph  @gaogao-mem @dholmes-ora 

I'm happy to learn from you. I didn't introduce this RCU to UL. The reason I added those 2 gtests is that I also realize how fragile it is. I would like to cover it using concurrent tests.

I just feel that it's incorrect to claim the program has data race by citing this: 

> If one evaluation modifies a memory location, and the other reads or modifies the same memory location, and if at least one of the evaluations is not an atomic operation, the behavior of the program is undefined (the program has a [data race](https://en.cppreference.com/w/cpp/language/memory_model)) unless there exists a happens-before relationship between these two evaluations.

In RCU technique, store/load a aligned pointer is an atomic operation. A pointer equals to a machine word. you can only see either older version or new version. One of the premise condition isn't standing. 

but I agree with your conclusion.  We need something to establish proper order inter-threads. C++ release-consume is perfect for this model. Without it, compiler may flip order on reader side and undermine the correctness.

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

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


More information about the hotspot-runtime-dev mailing list