Re: Let's drop support for named POSIX semaphores

On Monday, October 26th, 2026 at 1:06 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Andres Freund <andres(at)anarazel(dot)de> writes:
> > It's *really* annoying that window's WaitOnAddress() equivalent explicitly
> > requires the waiter and waker to be threads in the same process :(.
> > E.g. lwlocks would be faster *and* the code would be simpler if futexes could
> > be used everywhere.
>
> Well, in our hypothetical multithreaded future, that might be fine.
> I'm wondering how much change we should try to make in this area now,
> rather than after (or as part of) the multithreading work.
>
> regards, tom lane

I don't think Windows has to block this, and I don't think the API
would need to change when threads arrive.

Kernel futexes that work across processes exist on Linux, FreeBSD,
OpenBSD and NetBSD (both key shared waits on the backing VM object,
not the VA), DragonFly, and macOS 14.4+ via os_sync_wait_on_address()
with the SHARED flags, which is what Thomas's pg_futex branch uses
[0]. That leaves Windows, Solaris/illumos, AIX, Cygwin and older
macOS needing a fallback in any case, so the question is what the
fallback looks like rather than whether we need one.

Thomas's pg_futex.h already wraps the value in a struct to leave room
for one. The fallback I'd suggest is to embed a spinlock and a
proclist_head in that struct, and have waiters sleep on their own
PGPROC semaphore: enqueue, recheck the value, release, sleep; the
waker updates the value, dequeues, and posts. That is the same thing
lwlock.c and condition_variable.c already do by hand, done once.
Embedding the queue rather than using a parking lot hashed by address
matters because DSM segments map at different addresses in different
backends; the native kernels don't care, but a userspace hash would.

With that, LWLocks and CVs could be written once against pg_futex,
getting native futexes where the kernel has them and today's
behavior elsewhere, and the semaphore count fixups Andres mentioned
move into one place. In a multithreaded build Windows simply moves
to the native tier via WaitOnAddress(), and the generic fallback can
sit on pg_threads.h mtx/cnd the way Zig's std.Thread.Futex does [1].

I'd keep the API to 32-bit wait(expected, timeout), wake_one() and
wake_all(), since macOS and Windows can't wake an arbitrary count and
Linux and FreeBSD only wait on 32-bit words. Latches are out of scope:
a futex can't multiplex with sockets or postmaster death.

The open question for me is performance. Haris's futex-based
LWLockWaitListLock() patch [2] was a large win on Neoverse V3 but a
small loss on recent x86, so a futex LWLock needs real numbers, not
assumptions.

If there is any agreement on this approach I'd be happy to picked up
the lwlock-futex branch [3] and try the embedded-queue fallback on
top of it.

thoughts?

-greg

[0] https://github.com/macdice/postgres/commit/bf2ceb73fe8a48ece981a82ef103284e5dfc0a54
[1] https://github.com/ziglang/zig/blob/master/lib/std/Thread/Futex.zig
[2] https://postgr.es/m/DM6PR18MB29081469262A7BBCE85220B3A8112%40DM6PR18MB2908.namprd18.prod.outlook.com
[3] https://github.com/macdice/postgres/commits/lwlock-futex/