Re: unconstify equivalent for volatile

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: unconstify equivalent for volatile
Дата
Msg-id 85085186-DC69-4DEE-A322-7084C24DFFEF@anarazel.de
обсуждение исходный текст
Ответ на Re: unconstify equivalent for volatile  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: unconstify equivalent for volatile  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

On February 19, 2019 7:00:58 AM PST, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
>On 2019-02-18 21:25, Andres Freund wrote:
>> ISTM this one should rather be solved by removing all volatiles from
>> latch.[ch]. As that's a cross-process concern we can't rely on it
>> anyway (and have placed barriers a few years back to allay concerns /
>> bugs due to reordering).
>
>Aren't the volatiles there so that Latch variables can be set from
>signal handlers?

Why would they be required, given we have an explicit compiler & memory barrier? That forces the compiler to spill the
writesto memory already, even in a signal handler. And conversely the reading side is similarly forced - if not we have
abug in multi core systems - to read the variable from memory after a barrier. 

The real reason why variables commonly need to be volatile when used in signal handlers is not the signal handler side,
butthe normal code flow side. Without using explicit care the variable's value can be "cached"in a register, and a
changenot noticed. But as volatiles aren't sufficient for cross process safety, latches need more anyway. 

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: FOP warnings about id attributes in title tags
Следующее
От: Joe Conway
Дата:
Сообщение: Re: Some thoughts on NFS