On Sat, Nov 20, 2021 at 9:34 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > This has been fixed. So now there are working basic futexes on Linux,
> > macOS, {Free,Open,Net,Dragonfly}BSD (though capabilities beyond basic
> > wait/wake vary, as do APIs). So the question is whether it would be
> > worth trying to do our own futex-based semaphores, as sketched above,
> > just for the benefit of the OSes where the available built-in
> > semaphores are of the awkward SysV kind, namely macOS, NetBSD and
> > OpenBSD. Perhaps we shouldn't waste our time with that, and should
> > instead plan to use futexes for a more ambitious lwlock rewrite.
>
> I kind of like the latter idea, but I wonder how we make it coexist
> with (admittedly legacy) code for OSes that don't have usable futexes.
One very rough idea, not yet tried, is that they could keep using
semaphores, but use them to implement fake futexes. We'd put them in
wait lists that live in a shared memory hash table (the futex address
is the key, with some extra work needed for DSM-resident futexes),
with per-bucket spinlocks so that you can perform the value check
atomically with the decision to start waiting.
