On Tue, 13 Feb 2024 at 12:52, Andres Freund <and...@anarazel.de> wrote:
> Hi, > > On 2024-02-13 12:49:33 -0500, Dave Cramer wrote: > > > 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'd just ignore that, that's just pushing towards more modern stuff that's > more applicable to C++ than C. > > > > I did try using atomic_thread_fence as per atomic_thread_fence - > > cppreference.com > > <https://en.cppreference.com/w/c/atomic/atomic_thread_fence> > > The semantics of atomic_thread_fence are, uh, very odd. I'd just use > MemoryBarrier(). > > #define S_UNLOCK(lock) \ do { MemoryBarrier(); (*(lock)) = 0; } while (0) #endif Has no effect. I have no idea if that is what you meant that I should do ? Dave