> Date: Wed, 22 Feb 2023 12:57:24 +0000
> From: Taylor R Campbell <campbell+netbsd-tech-k...@mumble.net>
>
> I propose to delete current use of __HAVE_ATOMIC_AS_MEMBAR because it
> is a bad API, and replace it by one of two options:
>
> (a) Add membar_release_preatomic and membar_acquire_postatomic: noop
> if __HAVE_ATOMIC_AS_MEMBAR, alias for membar_release/acquire
> otherwise.
> [...]
> (b) Change the semantics of membar_release and membar_acquire so they
> are noops on platforms with __HAVE_ATOMIC_AS_MEMBAR, like x86.
> For ordering plain loads and stores there are still
> atomic_load_acquire and atomic_store_release.
A third option occurred to me this evening:
(c) Just make the membars unconditional -- take off the #ifndefs, but
don't add any new functions or change the semantics of existing
ones.
This would only hurt on platforms where __HAVE_ATOMIC_AS_MEMBAR
could be set (x86 and sparc/sparc64, to my knowledge, though only
x86 actually does set it) but that don't run in Total Store Order
(which x86 does and, as far as I'm aware, all real sparc/sparc64
hardware on the planet does too).
In other words, except perhaps for adding a trivial procedure call
on x86, it would have no performance impact on any architectures
in NetBSD, let alone any architectures I know about. We could
also make membar_* be macros expanding to __insn_barrier on x86 to
avoid the procedure call overhead.
The micro-optimization of __HAVE_ATOMIC_AS_MEMBAR presumably arose in
the first place at a time when the x86 membar_* did needless extra
work like LOCK ADD, LFENCE, MFENCE, or SFENCE, none of which are
needed in TSO except by membar_sync. Now that x86 membar_* are
correctly reduced to noops (except membar_sync) perhaps there's no
longer any need for this.
