On 2014-06-26 15:40:11 -0700, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > On 2014-06-26 14:13:07 -0700, Tom Lane wrote: > >> Surely it had better be a read barrier as well? > > > I don't immediately see why it has to be read barrier? Hoisting a load > > from after the release into the locked area of code should be safe? > > No doubt, but delaying a read till after the unlocking write would > certainly not be safe.
Right. What we actually want for locking is what several systems (e.g. C11, linux) coin acquire/release barriers. Not sure whether we should introduce a separate set of acquire/release macros, or "promote" our barriers to have stronger guarantees than the name implies. The definition as I understand it is: A acquire barrier implies that: * memory operations from after the barrier cannot appear to have happened before the barrier * but: memory operations from *before* the barrier are *not* guaranteed to be finished A finished release barrier implies: * stores from before the barrier cannot be moved past * loads from before the barrier cannot be moved past * but: reads from *after* the barrier might occur *before* the barrier. I believe that all our current barrier definitions (except maybe alpha which I haven't bothered to check thoroughly) satisfy those constraints. That's primarily because we don't have support for all that many platforms and use full memory barriers for read/write barriers in several places. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
