Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wKJ4D-000plS-1Z for pgsql-hackers@arkaria.postgresql.org; Tue, 05 May 2026 16:56:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wKJ4C-00Cy7P-0V for pgsql-hackers@arkaria.postgresql.org; Tue, 05 May 2026 16:56:16 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wKJ4B-00Cy7G-2m for pgsql-hackers@lists.postgresql.org; Tue, 05 May 2026 16:56:15 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wKJ49-00000000LQK-0f0O for pgsql-hackers@postgresql.org; Tue, 05 May 2026 16:56:14 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.18.1/8.18.1) with ESMTP id 645Gu9if532706; Tue, 5 May 2026 12:56:09 -0400 From: Tom Lane To: Nathan Bossart cc: pgsql-hackers@postgresql.org Subject: Re: small cleanup for s_lock.h In-reply-to: References: <369933.1777933007@sss.pgh.pa.us> Comments: In-reply-to Nathan Bossart message dated "Tue, 05 May 2026 11:08:38 -0500" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <532586.1778000057.0@sss.pgh.pa.us> Date: Tue, 05 May 2026 12:56:09 -0400 Message-ID: <532705.1778000169@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <532586.1778000057.1@sss.pgh.pa.us> Nathan Bossart writes: > Okay, here's a new version of the patch that I believe addresses both > points. This seems cleaner than what we have ... but ... After thinking some more I realized that what's confusing us here is an API-level problem. s_lock.h's header comment says * Usually, S_LOCK() is implemented in terms of even lower-level macros * TAS() and TAS_SPIN(): As things stand, we have no platforms where that's not the case, and so we've lost sight of the fact that the contract shouldn't be "you must provide TAS()". It should be "you must either provide S_LOCK(), or provide TAS() to base it on". A rough cut as to the right way to do this is attached. The main loose end here is that it's not very clear what s_lock.c's s_lock() should do if there's no TAS (and hence no TAS_SPIN). Maybe we should just not compile that function at all without TAS; if a platform provides a non-default S_LOCK that needs a helper function, it's on the platform to supply that helper. Also, after noting that HAS_TEST_AND_SET is referenced nowhere outside s_lock.h, I'm coming around to your previous position that it's redundant and we should drop it. This is mainly because it's not clear to me whether it should be set on a platform that provides S_LOCK but not TAS. I didn't touch that here though. Lastly, I definitely agree now that the file's header comment needs some work. Maybe this insight helps you with that? (One thing I noticed is that the ending comment about "Equivalent OS-supplied mutex routines could be used too" feels pretty obsolete. Maybe instead, "Equivalent compiler intrinsics are another popular option".) regards, tom lane ------- =_aaaaaaaaaa0 Content-Type: text/x-diff; name="clarify-S_LOCK-vs-TAS.patch"; charset="us-ascii" Content-ID: <532586.1778000057.2@sss.pgh.pa.us> Content-Description: clarify-S_LOCK-vs-TAS.patch Content-Transfer-Encoding: quoted-printable diff --git a/src/include/storage/s_lock.h b/src/include/storage/s_lock.h index c9e52511990..0a13c958fc8 100644 --- a/src/include/storage/s_lock.h +++ b/src/include/storage/s_lock.h @@ -652,19 +652,18 @@ spin_delay(void) #endif /* !defined(HAS_TEST_AND_SET) */ = = -/* Blow up if we didn't have any way to do spinlocks */ -#ifndef HAS_TEST_AND_SET -#error PostgreSQL does not have spinlock support on this platform. Pleas= e report this to pgsql-bugs@lists.postgresql.org. -#endif - - /* * Default Definitions - override these above as needed. */ = #if !defined(S_LOCK) +#if defined(TAS) #define S_LOCK(lock) \ (TAS(lock) ? s_lock((lock), __FILE__, __LINE__, __func__) : 0) +#else +/* Must provide S_LOCK, or a TAS macro to base it on */ +#error PostgreSQL does not have spinlock support on this platform. Pleas= e report this to pgsql-bugs@lists.postgresql.org. +#endif /* TAS */ #endif /* S_LOCK */ = #if !defined(S_UNLOCK) @@ -697,15 +696,10 @@ extern void s_unlock(volatile slock_t *lock); #define SPIN_DELAY() ((void) 0) #endif /* SPIN_DELAY */ = -#if !defined(TAS) -extern int tas(volatile slock_t *lock); /* in port/.../tas.s, or - * s_lock.c */ - -#define TAS(lock) tas(lock) -#endif /* TAS */ - #if !defined(TAS_SPIN) +#if defined(TAS) #define TAS_SPIN(lock) TAS(lock) +#endif /* TAS */ #endif /* TAS_SPIN */ = = ------- =_aaaaaaaaaa0--