Content-Type: multipart/alternative;
 boundary="------------vySgsWq5u6ExQwFnCymloIGZ"
Message-ID: <927941c8-e5a1-4787-bbd9-88f0d92b55d0@gmail.com>
Date: Thu, 23 Oct 2025 10:00:00 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: IO in wrong state on riscv64
To: Thomas Munro <thomas.munro@gmail.com>, Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>, greg@burd.me
References: <d79691be-22bd-457d-9d90-18033b78c40a@gmail.com>
 <CA+hUKG+X=FKYecrpZaWNkWJZkQQWu6v2LvcD4nof1UftF7nZ9A@mail.gmail.com>
 <60bbebf4-0a80-4e5f-83c0-311c85f6bd5c@gmail.com>
 <CA+hUKGKRZufVhDEc1NDUXXHpTd9Q8gmvqbU+2cOUJZnK_TYJGA@mail.gmail.com>
 <c4cf94c2-e61c-444b-814f-1df85e52a39f@gmail.com>
 <CA+hUKGLpP2T90M3eEPB95KfB4PtdfVnEUNH+aoRiXfSk-ODJkQ@mail.gmail.com>
 <f2378a85-c968-4ccf-acf3-bca6f5c50c87@gmail.com>
 <CA+hUKGKcdkNTkn9C2MT3zM3ZTVLZTZTiLKXkWVDYWh4w7MNACA@mail.gmail.com>
 <CA+hUKGJKqC2VSg8_MCB4_3air3Zhk8x8K99KxHtLuoFFdVFnvg@mail.gmail.com>
 <w3qc4gzqywinffeglpwyxbwocpsjvh3yqqy5d42zsqhciy3yr5@tb63f2ipdzrl>
 <CA+hUKGLJHW7QjNGpfo+yKD6GzhdVnHxaSf0QJZp4VTu7jAt68A@mail.gmail.com>
Content-Language: en-US
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: 
 <CA+hUKGLJHW7QjNGpfo+yKD6GzhdVnHxaSf0QJZp4VTu7jAt68A@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/927941c8-e5a1-4787-bbd9-88f0d92b55d0%40gmail.com>
Precedence: bulk

This is a multi-part message in MIME format.
--------------vySgsWq5u6ExQwFnCymloIGZ
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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
--------------vySgsWq5u6ExQwFnCymloIGZ
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Hello Thomas,<br>
      <br>
      23.10.2025 00:51, Thomas Munro wrote:<span
      style="white-space: pre-wrap">
</span></div>
    <blockquote type="cite"
cite="mid:CA+hUKGLJHW7QjNGpfo+yKD6GzhdVnHxaSf0QJZp4VTu7jAt68A@mail.gmail.com">
      <pre wrap="" class="moz-quote-pre">On a more practical note, Alexander, does this work?

 #if !defined(pg_read_barrier_impl) &amp;&amp; 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.
</pre>
    </blockquote>
    <br>
    Thank you for working on this!<br>
    <br>
    Unfortunately, this change doesn't lead to change in disassembly of<br>
    pgaio_io_wait(), produced with clang-19 -O1. That is, I'm getting
    the same<br>
    disassembly as the one I sent you before (error/pgaio_io_wait.asm).<br>
    I tried:<br>
     #if !defined(pg_read_barrier_impl) &amp;&amp;
    defined(HAVE_GCC__ATOMIC_INT32_CAS)<br>
     /* acquire semantics include read barrier semantics */<br>
    -#              define pg_read_barrier_impl()          
    __atomic_thread_fence(__ATOMIC_ACQUIRE)<br>
    +#              define pg_read_barrier_impl()           do { } while
    (0)<br>
     #endif<br>
    to make sure that the change of pg_read_barrier_impl() affects<br>
    pgaio_io_wait() and really saw a difference in the disassembly.<br>
    <br>
    I haven't run tests with the modified version yet, going to test
    later<br>
    just to be sure, but I suppose we want to see the binary code
    changed.<br>
    <br>
    Best regards,<br>
    Alexander<br>
  </body>
</html>

--------------vySgsWq5u6ExQwFnCymloIGZ--