Our "fallback" atomics implementation doesn't actually work - Mailing list pgsql-hackers

From Tom Lane
Subject Our "fallback" atomics implementation doesn't actually work
Date
Msg-id 14947.1475690465@sss.pgh.pa.us
Whole thread Raw
Responses Re: Our "fallback" atomics implementation doesn't actually work  (Andres Freund <andres@anarazel.de>)
Re: Our "fallback" atomics implementation doesn't actually work  (Andres Freund <andres@anarazel.de>)
Re: Our "fallback" atomics implementation doesn't actually work  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
I was trying to measure whether unnamed POSIX semaphores are any faster
or slower than the SysV kind.  Plain pgbench is not very helpful for
determining this, because we've optimized the system to the point that
you don't hit semop waits all that often.  So I tried this:

configure USE_UNNAMED_POSIX_SEMAPHORES=1 --disable-cassert --disable-spinlocks --disable-atomics

figuring that that would stress the semop paths nicely.  But what I find
is that the database locks up after a few seconds of running "pgbench -S
-c 20 -j 20 bench" on an 8-core RHEL6 machine.

I think what is happening is that there are circular assumptions that end
up trying to implement a spinlock in terms of a spinlock, or otherwise
somehow recursively use the process's semaphore.  It's a bit hard to tell
though because the atomics code is such an underdocumented rat's nest of
#ifdefs.

Curiously, I did not see such a hang with regular SysV semaphores.
That may be just a timing thing, or it may have something to do with
POSIX semaphores being actually futexes on this platform (so that there
is state inside the process not outside it).

No hang observed without --disable-atomics, either.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Cardinality estimation for group by
Next
From: Andres Freund
Date:
Subject: Re: Our "fallback" atomics implementation doesn't actually work