On 2017-11-21 19:02:01 -0500, Tom Lane wrote: > andres@xxxxxxxxxxx (Andres Freund) writes: > > On 2017-11-21 18:50:05 -0500, Tom Lane wrote: > >> (If Justin saw that while still on 9.6, then it'd be worth looking > >> closer.) > > > Right. I took this to be referring to something before the current > > migration, but I might have overinterpreted things. There've been > > various forks/ports of pg around that had hand-coded replacements with > > futex usage, and there were definitely buggy versions going around a few > > years back. > > Poking around in the archives reminded me of this thread: > https://www.postgresql.org/message-id/flat/14947.1475690465@xxxxxxxxxxxxx > which describes symptoms uncomfortably close to what Justin is showing. > > I remember speculating that the SysV-sema implementation, because it'd > always enter the kernel, would provide some memory barrier behavior > that POSIX-sema code based on futexes might miss when taking the no-wait > path. I think I was speculating that, but with the benefit of just having had my fourth espresso: I've a hard time believing that - the fast path in a futex pretty much has to be either a test-and-set or a compare-and-exchange type operation. See e.g. the demo of futex usage in the futex(2) manpage: while (1) { /* Is the futex available? */ if (__sync_bool_compare_and_swap(futexp, 1, 0)) break; /* Yes */ /* Futex is not available; wait */ s = futex(futexp, FUTEX_WAIT, 0, NULL, NULL, 0); if (s == -1 && errno != EAGAIN) errExit("futex-FUTEX_WAIT"); } I can't see how you could make use of futexes without some kind of barrier semantics, at least on x86. Greetings, Andres Freund
