Re: 【memory barrier】Should we update the README.barrier description.

On Sun, 10 May 2020 at 02:01, postgresql_2016(at)163(dot)com <
postgresql_2016(at)163(dot)com> wrote:

> Hi
>
> When I read the introduction of Weaknesses of Memory Barriers in
> README.barrier, the following maybe out-of-date now.
>
> Even very simple write operations often require additional synchronization.
> For example, it's not safe for multiple writers to simultaneously execute
> this code (supposing x is a pointer into shared memory):
>
> x->foo++;
>
> Although this may compile down to a single machine-language instruction,
> the CPU will execute that instruction by reading the current value of foo,
> adding one to it, and then storing the result back to the original address.
> If two CPUs try to do this simultaneously, both may do their reads before
> either one does their writes. *Eventually we might be able to use an
> atomic
> fetch-and-add instruction for this specific case on architectures that
> support
> it, but we can't rely on that being available everywhere, and we currently
> have no support for it at all. Use a lock.*
>

> Now, the postgres has support atomic operation and use it

Yes, those docs can change now.

> in some cases we
> have not use the lock.
>

Which code does not use the lock?

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
Mission Critical Databases