Obsolete use of volatile in walsender.c, walreceiver.c, walreceiverfuncs.c?

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Obsolete use of volatile in walsender.c, walreceiver.c, walreceiverfuncs.c?
Дата
Msg-id CAEepm=2f-N5MD+xYYyO=yBpC9SoOdCdrdiKia9_oLTSiu1uBtA@mail.gmail.com
обсуждение исходный текст
Ответы Re: Obsolete use of volatile in walsender.c, walreceiver.c, walreceiverfuncs.c?  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: Obsolete use of volatile in walsender.c, walreceiver.c, walreceiverfuncs.c?  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Hi

In walsender.c, walreceiver.c, walreceiverfuncs.c there are several
places where volatile qualifiers are used apparently only to prevent
reordering around spinlock operations.  My understanding is that if
potential load/store reordering around spinlock operations is the only
reason for using volatile, 0709b7ee72e4bc71ad07b7120acd117265ab51d0
made it unnecessary.  For example see
6ba4ecbf477e0b25dd7bde1b0c4e07fc2da19348 which stripped some volatile
qualifiers out of xlog.c.

I did notice that sometimes walsnd->pid is read without acquiring the
spinlock.  Is that actually OK anyway (taking a stale and inconsistent
view of the contents of walsnd->pid WRT to the other members that are
later accessed while holding the spinlock)?

Would it be safe to remove all those volatile qualifiers, something
like in the attached, or am I missing something?

(There is also code in syncrep.c that is reading shmem without
acquiring spinlocks using volatile qualifiers, that is a different
situation, though I don't yet see how it is ordering sensitive or
reading the same object repeatedly, but I'm not talking about that
here).

--
Thomas Munro
http://www.enterprisedb.com

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "David E. Wheeler"
Дата:
Сообщение: tsvector work with citext
Следующее
От: Tom Lane
Дата:
Сообщение: Re: tsvector work with citext