On 2014-06-26 14:13:07 -0700, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > I think we should rework things so that we fall back to > > pg_write_barrier(), (*((volatile slock_t *) (lock)) = 0) instead of what > > we have right now. > > 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? Note that 'bad' reads can only happen for variables which aren't protected by the spinlock since the S_LOCK needs to have acquire semantics and no other process can modify protected variables concurrently. The important thing is that all modifications that have been done inside the spinlock are visible to other backends and that no writes are moved outside the protected are. > And S_LOCK the same? It better be a read barrier, yes. I haven't checked yet, but I assume that pretty much all TAS/tas implementation already guarantee that. I think if not we'd seen problems. Well, at least on platforms that receive testing under concurrent circumstances :/ 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
