Our "fallback" atomics implementation doesn't actually work

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Our "fallback" atomics implementation doesn't actually work
Дата
Msg-id 14947.1475690465@sss.pgh.pa.us
обсуждение исходный текст
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Cardinality estimation for group by
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Our "fallback" atomics implementation doesn't actually work