On Fri, Sep 26, 2014 at 8:55 AM, Oskari Saarenmaa <o...@ohmu.fi> wrote: >> So you think a read barrier is the same thing as an acquire barrier >> and a write barrier is the same as a release barrier? That would be >> surprising. It's certainly not true in general. > > The above doc describes the difference: read barrier requires loads before > the barrier to be completed before loads after the barrier - an acquire > barrier is the same, but it also requires loads to be complete before stores > after the barrier. > > Similarly write barrier requires stores before the barrier to be completed > before stores after the barrier - a release barrier is the same, but it also > requires loads before the barrier to be completed before stores after the > barrier. > > So acquire is read + loads-before-stores and release is write + > loads-before-stores.
Hmm. My impression was that an acquire barrier means that loads and stores can migrate forward across the barrier but not backward; and that a release barrier means that loads and stores can migrate backward across the barrier but not forward. I'm actually not really sure what this means unless the barrier also does something in and of itself. For example, consider this: some stuff CAS(&lock, 0, 1) // i am an acquire barrier more stuff lock = 0 // i am a release barrier even more stuff If the CAS() and lock = 0 instructions were FULL barriers, then we'd be saying that the stuff that happens in the critical section needs to be exactly "more stuff". But if they are acquire and release barriers, respectively, then the CPU is allowed to move "some stuff" or "even more stuff" into the critical section; but what it can't do is move "more stuff" out. Now if you just have a naked acquire barrier that is not doing anything itself, I don't really know what the semantics of that should be. Say I want to appear to only change things while flag is 1, so I write this code: flag = 1 acquire barrier things++ release barrier flag = 0 With the definition you (and Oracle) propose, this won't work, because there's nothing to keep the modification of things from being reordered before flag = 1. What good is that? Apparently, I don't have any idea! -- 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
