pg.ddx.io pgsql-docs@postgresql.org mailing list archive
help / color / mirror / Atom feed【memory barrier】Should we update the README.barrier description.
2+ messages / 2 participants
[nested] [flat]
* 【memory barrier】Should we update the README.barrier description.
@ 2020-05-10 01:01 postgresql_2016@163.com <postgresql_2016@163.com>
2020-05-11 06:57 ` Re: 【memory barrier】Should we update the README.barrier description. Simon Riggs <simon@2ndquadrant.com>
0 siblings, 1 reply; 2+ messages in thread
From: postgresql_2016@163.com @ 2020-05-10 01:01 UTC (permalink / raw)
To: pgsql-docs
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, in some cases we
have not use the lock.
--
Sent from: https://www.postgresql-archive.org/PostgreSQL-docs-f2165602.html
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: 【memory barrier】Should we update the README.barrier description.
2020-05-10 01:01 【memory barrier】Should we update the README.barrier description. postgresql_2016@163.com <postgresql_2016@163.com>
@ 2020-05-11 06:57 ` Simon Riggs <simon@2ndquadrant.com>
0 siblings, 0 replies; 2+ messages in thread
From: Simon Riggs @ 2020-05-11 06:57 UTC (permalink / raw)
To: postgresql_2016@163.com <postgresql_2016@163.com>; +Cc: pgsql-docs
On Sun, 10 May 2020 at 02:01, postgresql_2016@163.com <
postgresql_2016@163.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
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2020-05-11 06:57 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-05-10 01:01 【memory barrier】Should we update the README.barrier description. postgresql_2016@163.com <postgresql_2016@163.com>
2020-05-11 06:57 ` Simon Riggs <simon@2ndquadrant.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox