On Wed, Jun 18, 2014 at 12:13 PM, Andres Freund <and...@2ndquadrant.com> wrote: > There might be cases where that's true, but in the majority of cases > where the variable isn't highly contended it's just about the same. In > many cases the microcode will implement atomic ops using ll/sc > operations internally anyway.
But if the variable isn't highly contended, then why are we messing around with atomic ops in the first place? > I'm fine with always implementing everything but tas, cas, add ontop of > cas for now. I want or/and/sub/... to be conveniently available to C > code, but they don't need to be based on hardware ops. Having open-coded > versions of the above in several places sounds like a horrible idea to > me. Both, because we might want to optimize it at some point and because > it's horrible readability wise. OK, so if we're only going to have TAS, CAS, and fetch-and-add as primitives (which sounds sensible to me) and implement the rest in terms of those for now, then the table on the wiki only needs one more column: information about support for fetch-and-add. >> More than that, I actually really hate >> things that don't have a configure option, like WAL_DEBUG, because you >> have to change a checked-in file, which shows up as a diff, and if >> you're not careful you check it in, and if you are careful it still >> gets blown away every time you git reset --hard, which I do a lot. I >> think the fact that both Heikki and I on separate occasions have made >> commits enabling WAL_DEBUG shows pretty clearly the weaknesses of that >> method of doing business. > > Why don't you pass it to configure or add it in Makefile.custom? That's > what I do. Yeah, I should probably do that instead. But I still think the point that two different commiters have managed to flip that flag by accident is telling. -- 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