Re: IO in wrong state on riscv64

Поиск
Список
Период
Сортировка
От Alexander Lakhin
Тема Re: IO in wrong state on riscv64
Дата
Msg-id 927941c8-e5a1-4787-bbd9-88f0d92b55d0@gmail.com
обсуждение исходный текст
Ответ на Re: IO in wrong state on riscv64  (Thomas Munro <thomas.munro@gmail.com>)
Ответы Re: IO in wrong state on riscv64
Список pgsql-hackers
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

В списке pgsql-hackers по дате отправления: