Re: IO in wrong state on riscv64

Hello Thomas,

23.10.2025 00:51, Thomas Munro wrote:
> On a more practical note, Alexander, does this work?
>
> #if !defined(pg_read_barrier_impl) && defined(HAVE_GCC__ATOMIC_INT32_CAS)
> /* acquire semantics include read barrier semantics */
> -# define pg_read_barrier_impl()
> __atomic_thread_fence(__ATOMIC_ACQUIRE)
> +# define pg_read_barrier_impl() do {
> __atomic_signal_fence(__ATOMIC_ACQUIRE);
> __atomic_thread_fence(__ATOMIC_ACQUIRE); } while (0)
> #endif
>
> Someone might want to write an arch-riscv.h that spits out the asm
> instead (should be just FENCE R, R and FENCE W, W as far as I can see,
> which might be slightly better than what acquire/release generate, on
> paper at least), but apparently this problem is wider than RISCV so we
> need a general solution anyway.

Thank you for working on this!

Unfortunately, this change doesn't lead to change in disassembly of
pgaio_io_wait(), produced with clang-19 -O1. That is, I'm getting the same
disassembly as the one I sent you before (error/pgaio_io_wait.asm).
I tried:
 #if !defined(pg_read_barrier_impl) && defined(HAVE_GCC__ATOMIC_INT32_CAS)
 /* acquire semantics include read barrier semantics */
-#              define pg_read_barrier_impl() __atomic_thread_fence(__ATOMIC_ACQUIRE)
+#              define pg_read_barrier_impl()           do { } while (0)
 #endif
to make sure that the change of pg_read_barrier_impl() affects
pgaio_io_wait() and really saw a difference in the disassembly.

I haven't run tests with the modified version yet, going to test later
just to be sure, but I suppose we want to see the binary code changed.

Best regards,
Alexander