NetBSD Problem Report #57439

From www@netbsd.org  Fri May 26 11:33:58 2023
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 49ED61A9238
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 26 May 2023 11:33:58 +0000 (UTC)
Message-Id: <20230526113356.8CE421A9239@mollari.NetBSD.org>
Date: Fri, 26 May 2023 11:33:56 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: libpthread still uses legacy membar_exit/enter instead of membar_release/acquire
X-Send-Pr-Version: www-1.0

>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!

Home	PR Database Search