@@ -103,7 +103,7 @@ performed before the barrier, and vice-versa.
103103
104104Although this code will work, it is needlessly inefficient. On systems with
105105strong memory ordering (such as x86), the CPU never reorders loads with other
106- loads, nor stores with other stores. It can, however, allow a load to
106+ loads, nor stores with other stores. It can, however, allow a load to be
107107performed before a subsequent store. To avoid emitting unnecessary memory
108108instructions, we provide two additional primitives: pg_read_barrier(), and
109109pg_write_barrier(). When a memory barrier is being used to separate two
@@ -155,18 +155,16 @@ Although this may compile down to a single machine-language instruction,
155155the CPU will execute that instruction by reading the current value of foo,
156156adding one to it, and then storing the result back to the original address.
157157If two CPUs try to do this simultaneously, both may do their reads before
158- either one does their writes. Eventually we might be able to use an atomic
159- fetch-and-add instruction for this specific case on architectures that support
160- it, but we can't rely on that being available everywhere, and we currently
161- have no support for it at all. Use a lock.
158+ either one does their writes. Such a case could be made safe by using an
159+ atomic variable and an atomic add. See port/atomics.h.
162160
1631612. Eight-byte loads and stores aren't necessarily atomic. We assume in
164162various places in the source code that an aligned four-byte load or store is
165163atomic, and that other processes therefore won't see a half-set value.
166164Sadly, the same can't be said for eight-byte value: on some platforms, an
167165aligned eight-byte load or store will generate two four-byte operations. If
168- you need an atomic eight-byte read or write, you must make it atomic with a
169- lock.
166+ you need an atomic eight-byte read or write, you must either serialize access
167+ with a lock or use an atomic variable .
170168
1711693. No ordering guarantees. While memory barriers ensure that any given
172170process performs loads and stores to shared memory in order, they don't
0 commit comments