On Sat, Jun 28, 2014 at 4:31 AM, Andres Freund <and...@2ndquadrant.com> wrote: >> > Do we want to introduce acquire/release barriers? Or do we want to >> > redefine the current barriers to be strong enough for that? >> >> Well, unless we're prepared to dump support for an awful lot of >> platfomrs, trying to support acquire and release barriers on every >> platform we support is a doomed effort. > > Hm? Just declare them to be as heavy as we need them? Already several > platforms fall back to more heavyweight operations than necessary?
Can't we keep this simple for starters? Strength-reducing the existing operations is yet a third problem, on top of the already-existing problems of (1) making spinlock operations compiler barriers and (2) fixing any buggy implementations. I'm explicitly trying to avoid defining this in a way that means we need a Gigantic Patch that Changes Everything. >> The definitions of the >> barriers implemented by barrier.h are the same as the ones that Linux >> has (minus read-barrier-depends) > > Linux has smb_load_acquire()/smp_store_release() for locks on all > platforms. You mean "smp". >> If we were going >> to use any of those in s_lock.h, it'd have to be pg_memory_barrier(), >> but I don't think making s_lock.h dependent on barrier.h is the way to >> go. I think we should just adjust s_lock.h in a minimal way, using >> inline assembler or tweaking the existing assembler or whatever. > > Isn't that just going to be repeating the contents of barrier.h pretty > much again? No, I think it's going to be *much* simpler than that. How about I take a crack at this next week and then either (a) I'll see why it's a bad idea and we can go from there or (b) you can review what I come up with and tell me why it sucks? > How are you suggesting we deal with the generic S_UNLOCK > case without having a huge ifdef? > Why do we build an abstraction layer (barrier.h) and then not use it? Because (1) the abstraction doesn't fit very well unless we do a lot of additional work to build acquire and release barriers for every platform we support and (2) I don't have much confidence that we can depend on the spinlock fallback for barriers without completely breaking obscure platforms, and I'd rather make a more minimal set of changes. -- 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
