Re: [PATCH] Add native windows on arm64 support
От | Dave Cramer |
---|---|
Тема | Re: [PATCH] Add native windows on arm64 support |
Дата | |
Msg-id | CADK3HHJHpwkbZgZdmg+sa5BqFaNhRA3HpQOkHEJ1Uy19jdtaag@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Add native windows on arm64 support (Dave Cramer <davecramer@postgres.rocks>) |
Ответы |
Re: [PATCH] Add native windows on arm64 support
|
Список | pgsql-hackers |
On Tue, 13 Feb 2024 at 16:28, Dave Cramer <davecramer@postgres.rocks> wrote:
On Tue, 13 Feb 2024 at 12:52, Andres Freund <andres@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)#endifHas no effect.I have no idea if that is what you meant that I should do ?Dave
Revisiting this:
Andrew, can you explain the difference between ninja test (which passes) and what the build farm does. The buildfarm crashes.
Dave
В списке pgsql-hackers по дате отправления: