1berry/postgres
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Require memory barrier support.

Browse Source 
Previously we had a fallback implementation that made a harmless system
call, based on the assumption that system calls must contain a memory
barrier.  That shouldn't be reached on any current system, and it seems
highly likely that we can easily find out how to request explicit memory
barriers, if we've already had to find out how to do atomics on a
hypothetical new system.

Removed comments and a function name referred to a spinlock used for
fallback memory barriers, but that changed in 1b468a13, which left some
misleading words behind in a few places.

Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>
Suggested-by: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/721bf39a-ed8a-44b0-8b8e-be3bd81db748%40technowledgy.de
Discussion: https://postgr.es/m/3351991.1697728588%40sss.pgh.pa.us
This commit is contained in:
Thomas Munro 2024-07-30 22:16:50 +12:00
parent a011dc399c
commit 83aadbeb96
4 changed files with 4 additions and 49 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
src/backend/port/atomics.c
View File

@ -17,29 +17,6 @@
#include "port/atomics.h"
#include "storage/spin.h"
#ifdef PG_HAVE_MEMORY_BARRIER_EMULATION
#ifdef WIN32
#error "barriers are required (and provided) on WIN32 platforms"
#endif
#include <signal.h>
#endif
#ifdef PG_HAVE_MEMORY_BARRIER_EMULATION
void
pg_spinlock_barrier(void)
{
/*
* NB: we have to be reentrant here, some barriers are placed in signal
* handlers.
*
* We use kill(0) for the fallback barrier as we assume that kernels on
* systems old enough to require fallback barrier support will include an
* appropriate barrier while checking the existence of the postmaster pid.
*/
(void) kill(PostmasterPid, 0);
}
#endif
#ifdef PG_HAVE_ATOMIC_U64_SIMULATION

4
src/include/port/atomics.h
View File

@ -101,6 +101,10 @@
#if !defined(pg_compiler_barrier_impl)
#error "could not find an implementation of pg_compiler_barrier"
#endif
#if !defined(pg_memory_barrier_impl)
#error "could not find an implementation of pg_memory_barrier_impl"
#endif
/*
* Provide a spinlock-based implementation of the 64 bit variants, if

16
src/include/port/atomics/fallback.h
View File

@ -17,22 +17,6 @@
# error "should be included via atomics.h"
#endif
#ifndef pg_memory_barrier_impl
/*
* If we have no memory barrier implementation for this architecture, we
* fall back to acquiring and releasing a spinlock.
*
* It's not self-evident that every possible legal implementation of a
* spinlock acquire-and-release would be equivalent to a full memory barrier.
* For example, I'm not sure that Itanium's acq and rel add up to a full
* fence. But all of our actual implementations seem OK in this regard.
*/
#define PG_HAVE_MEMORY_BARRIER_EMULATION
extern void pg_spinlock_barrier(void);
#define pg_memory_barrier_impl pg_spinlock_barrier
#endif
#if !defined(PG_HAVE_ATOMIC_U64_SUPPORT)

10
src/include/port/atomics/generic.h
View File

@ -135,19 +135,9 @@ pg_atomic_unlocked_test_flag_impl(volatile pg_atomic_flag *ptr)
static inline void
pg_atomic_clear_flag_impl(volatile pg_atomic_flag *ptr)
{
/*
* Use a memory barrier + plain write if we have a native memory
* barrier. But don't do so if memory barriers use spinlocks - that'd lead
* to circularity if flags are used to implement spinlocks.
*/
#ifndef PG_HAVE_MEMORY_BARRIER_EMULATION
/* XXX: release semantics suffice? */
pg_memory_barrier_impl();
pg_atomic_write_u32_impl(ptr, 0);
#else
uint32 value = 1;
pg_atomic_compare_exchange_u32_impl(ptr, &value, 0);
#endif
}
#elif !defined(PG_HAVE_ATOMIC_TEST_SET_FLAG)