RFR: 8325937: runtime/handshake/HandshakeDirectTest.java causes "monitor end should be strictly below the frame pointer" assertion failure on AArch64 [v2]

[Erik Österlund]

On Thu, 3 Oct 2024 19:30:25 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Yes, that's right. Code in critical sections isn't racy, by definition.

I suppose it depends on what we mean by racy. The critical sections are atomic if synchronized appropriately, but with only acquire/release semantics (what glibc seemingly does in practice), they might for example be observed to happen in inconsistent orders. I'll try to refrain myself from talking about the solution domain for now, but rather look at the problem domain. Consider for example the following mutex IRIW litmus test:

T1: synchronized (m1) { *v1 = 1; }
T2: synchronized (m2) { *v2 = 1; }
T3: synchronized (m1) { l1 = *v1; } synchronized (m2) { l2 = *v2; }
T4: synchronized (m2) { r2 = *v2; } synchronized (m1) { r1 = *v1; }

In this example, we have two global variables v1 and v2 that has a corresponding mutex me and m2. The global variables are read and written atomically under the corresponding lock. But with only acquire/release semantics in the lock, it is possible for the mutations from T1 and T2 to be observed to happen in inconsistent orders such as { l1: 1, l2: 0,  r1: 0, r2: 1 }. It would then appear to T3 that the atomic mutation of T1 happened-before the atomic mutation of T2, while from the point of view of T4, it would appear that the opposite happened.

Here is another example involving two threads.

T1: synchronized (m1) { *v1 = 1; } synchronized (m2) { l2 = *v2; }
T2: synchronized (m2) { *v2 = 1; } synchronized (m1) { r1 = *v1; }

Again, we have a situation where the critical sections ensure *atomicity* of the involved variables. But the ordering is again allowed to be inconsistent. The critical sections of T1 and T2 may appear to reorder.

In summary acquire/release locking and unlocking guarantees that the critical sections are atomic. But it allows the order of the atomic critical sections to reorder and be observed to happen in an inconsistent order across threads. While that isn't an atomicity problem, it's still seemingly "racy" to me. So that's at least worth considering in the problem domain of accepting acquire/release locking.

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

PR Comment: https://git.openjdk.org/jdk/pull/21295#issuecomment-2393116026