Re: unconstify equivalent for volatile

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

On 2019-02-19 11:48:16 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > The real reason why variables commonly need to be volatile when used in
> > signal handlers is not the signal handler side, but the normal code flow
> > side.
> 
> Yeah, exactly.  You have not explained why it'd be safe to ignore that.

Because SetLatch() is careful to have a pg_memory_barrier() before
touching shared state and conversely so are ResetLatch() (and
WaitEventSetWait(), which already has no volatiles). And if we've got
this wrong they aren't safe for shared latches, because volatiles don't
enforce meaningful ordering on weakly ordered architectures.

But even if we were to decide we'd want to keep a volatile in SetLatch()
- which I think really would only serve to hide bugs - that'd not mean
it's a good idea to keep it on all the other functions in latch.c.

Greetings,

Andres Freund


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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Some thoughts on NFS
Следующее
От: Tom Lane
Дата:
Сообщение: Re: speeding up planning with partitions