On Fri, Oct 29, 2021 at 4:54 PM Thomas Munro <thomas.mu...@gmail.com> wrote: > On Sun, Oct 24, 2021 at 10:50 PM Thomas Munro <thomas.mu...@gmail.com> wrote: > > Sadly, although the attached proof-of-concept patch allows a > > PREFERRED_SEMAPHORES=FUTEX build to pass tests on macOS (which also > > lacks native unnamed semas), FreeBSD and Linux (which don't need this > > but are interesting to test), and it also works on OpenBSD with > > shared_memory_type=sysv, it doesn't work on OpenBSD with > > shared_memory_type=mmap (the default). I suspect OpenBSD's futex(2) > > has a bug: inherited anonymous shared mmap memory seems to confuse it > > so that wakeups are lost. Arrrgh! > > FWIW I'm trying to follow up with the OpenBSD list over here, because > it'd be nice to get that working: > > https://marc.info/?l=openbsd-misc&m=163524454303022&w=2
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.