lib/57439: libpthread still uses legacy membar_exit/enter instead of membar_release/acquire

[campbell+netbsd%mumble.net@localhost]

>Number:         57439
>Category:       lib
>Synopsis:       libpthread still uses legacy membar_exit/enter instead of membar_release/acquire
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri May 26 11:35:00 +0000 2023
>Originator:     Taylor R Campbell
>Release:        current
>Organization:
The MemBarSD Pthreadation
>Environment:
burning from excessive power consumption, maybe we can save it with micro-optimizations
>Description:
membar_enter, as inherited from Solaris, is documented as a store-before-load/store barrier.

Store-before-load/store is extremely seldom useful -- it means there's an instance of Dekker's algorithm somewhere, which usually occurs only by accident or in obscure protocols; there is essentially one paired case in the kernel at the moment, in a slow path.  And on every architecture I'm aware of (except possibly riscv but it's likely this applies to all real-world riscv too), it is just as expensive as membar_sync -- the most expensive barrier, and costly even on strongly ordered CPUs like x86 and sparc in TSO which have no need for explicit barriers otherwise.

This is often mistakenly paired with membar_exit, a load/store-before-store barrier, when most applications really just need load/store-before-store and _load_-before-load/store, which is much cheaper (and a no-op on x86 and sparc TSO).  So we introduced membar_release (load/store-before-store) and membar_acquire (load-before-load/store) to serve the vast majority of use cases better and more cheaply.  (membar_exit is now a legacy alias for membar_release; membar_release was introduced to match the nomenclature in the literature and make the release/acquire pairing more obvious.)

libpthread still uses the legacy membar_exit/enter extensively.  I suspect most or all of these should be membar_release/acquire instead, which would be much cheaper (especially on architectures like Arm which don't define PTHREAD__ATOMIC_IS_MEMBAR to elide most of the membars), but it takes some careful thought in an audit to be confident about this change.
>How-To-Repeat:
code inspection
>Fix:
Yes, please!