On Fri, Aug 21, 2015 at 2:31 PM, Andres Freund <and...@anarazel.de> wrote: > No, if it's paired like that, I don't think it's allowed to fail. > > But, as the code stands, there's absolutely no guarantee you're not > seeing something like: > P1: a = 0; > P1: b = 0; > P1: PGSemaphoreLock(&P1); > P2: a = 1; > P2: PGSemaphoreUnlock(&P1); -- unrelated, as e.g. earlier by ProcSendSignal > P1: Assert(a == b == 1); > P2: b = 1; > P2: PGSemaphoreUnlock(&P1); > > if the pairing is like this there's no guarantees anymore, right? Even > if a and be were set before P1's assert, the thing would be allowed to > fail, because the store to a or b might each be visible since there's no > enforced ordering.
Hmm, I see your point. So I agree with your proposed fix then. That kinda sucks that we have to do all those gymnastics, though: that's a lot more complicated than what we have right now. -- 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
