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