On Wed, Jun 18, 2014 at 12:13 PM, Andres Freund <andres@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
