Dave Cramer www.postgres.rocks
On Mon, 12 Feb 2024 at 16:19, Andres Freund <and...@anarazel.de> wrote: > Hi, > > On 2024-02-12 12:50:12 -0800, Andres Freund wrote: > > On 2024-02-12 13:28:40 -0500, Andrew Dunstan wrote: > > I wonder if this indicates that we are either missing memory barriers > > somewhere or that the memory barriers we end up with on msvc + arm aren't > > correct? Either could explain why the problem doesn't occur when > building > > with optimizations. > > I think I might have been on to something - if my human emulation of a > preprocessor isn't wrong, we'd end up with > > #define S_UNLOCK(lock) \ > do { _ReadWriteBarrier(); (*(lock)) = 0; } while (0) > > on msvc + arm. And that's entirely insufficient - _ReadWriteBarrier() just > limits *compiler* level reordering, not CPU level reordering. I think it's > even insufficient on x86[-64], but it's definitely insufficient on arm. > In fact ReadWriteBarrier has been deprecated _ReadWriteBarrier | Microsoft Learn <https://learn.microsoft.com/en-us/cpp/intrinsics/readwritebarrier?view=msvc-170> I did try using atomic_thread_fence as per atomic_thread_fence - cppreference.com <https://en.cppreference.com/w/c/atomic/atomic_thread_fence> However for some reason including #include <stdatomic.h> causes a bunch of compiler errors. c:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include\vcruntime_c11_stdatomic.h(36): error C2061: syntax error: identifier 'atomic_bool' Dave