On Tue, Jul 8, 2014 at 2:21 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Thu, Jul 3, 2014 at 10:56 AM, Amit Kapila <amit.kapil...@gmail.com> > wrote: >> On Tue, Jul 1, 2014 at 4:10 PM, Andres Freund <and...@2ndquadrant.com> >> wrote: > > Further review of patch: > 1. > /* > * pg_atomic_test_and_set_flag - TAS() > * > * Acquire/read barrier semantics. > */ > STATIC_IF_INLINE_DECLARE bool > pg_atomic_test_set_flag(volatile pg_atomic_flag *ptr); > > a. I think Acquire and read barrier semantics aren't equal. > With acquire semantics, "the results of the operation are available before > the > results of any operation that appears after it in code" which means it > applies > for both load and stores. Definition of read barrier just ensures loads. > > So will be right to declare like above in comments?
Yeah. Barriers can be by the operations they keep from being reordered (read, write, or both) and by the direction in which they prevent reordering (acquire, release, or both). So in theory there are 9 combinations: read barrier (both directions) read barrier (acquire) read barrier (release) write barrier (both directions) write barrier (acquire) write barrier (both directions) full barrier (both directions) full barrier (acquire) full barrier (release) To make things more confusing, a read barrier plus a write barrier need not equal a full barrier. Read barriers prevent reads from being reordered with other reads, and write barriers keep writes from being reordered with other writes, but neither prevents a read from being reordered relative to a write. A full barrier, however, must prevent all reordering: read/read, read/write, write/read, and write/write. Clarity here is essential. barrier.h only proposed to implement the following: read barrier (both directions), write barrier (both directions), full barrier (both directions) The reason I did that is because it seemed to be more or less what Linux was doing, and it's generally suitable for lock-less algorithms. The acquire and release semantics come into play specifically when you're using barriers to implement locking primitives, which is isn't what I was trying to enable. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
