Re: better atomics - v0.5

Поиск
Список
Период
Сортировка
От Martijn van Oosterhout
Тема Re: better atomics - v0.5
Дата
Msg-id 20140711195619.GA22880@svana.org
обсуждение исходный текст
Ответ на Re: better atomics - v0.5  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: better atomics - v0.5  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Thu, Jul 10, 2014 at 08:46:55AM +0530, Amit Kapila wrote:
> As per my understanding of the general theory around barriers,
> read and write are defined to avoid reordering due to compiler and
> full memory barriers are defined to avoid reordering due to processors.
> There are some processors that support instructions for memory
> barriers with acquire, release and fence semantics.

Not exactly, both compilers and processors can rearrange loads and
stores.  Because the architecture most developers work on (x86) has
such a strong memory model (it's goes to lot of effort to hide
reordering) people are under the impression that it's only the compiler
you need to worry about, but that's not true for any other
architechture.

Memory barriers/fences are on the whole discouraged if you can use
acquire/release semantics because the latter are faster and much easier
to optimise for.

I strongly recommend the "Atomic Weapons" talk on the C11 memory model
to help understand how they work. As a bonus it includes correct
implementations for the major architectures.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> He who writes carelessly confesses thereby at the very outset that he does
> not attach much importance to his own thoughts.  -- Arthur Schopenhauer

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Over-optimization in ExecEvalWholeRowVar
Следующее
От: Robert Haas
Дата:
Сообщение: Re: proposal: rounding up time value less than its unit.