On Sun, 10 May 2020 at 02:01, postgresql_2...@163.com < postgresql_2...@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
