Robert Haas <robertmh...@gmail.com> writes: > On Mon, Jun 23, 2014 at 11:16 AM, Andres Freund <and...@2ndquadrant.com> > wrote: >> Since fetch-and-add is trivially implemented using CAS, there's not much >> need to distinguish between CAS and CAS + fetch_and_add. From my POV the >> restriction to just CAS/fetch_and_add isn't actually buying much. Pretty >> much all platforms but older gcc ones have atomic intrinsics since >> forever. Once you've dug up the documentation for one operation not >> adding two more or so doesn't save much.
> Again, the concern that was expressed at the developer's meeting was > that the performance characteristics of the CAS loop might be > significantly different from a native atomic op as to cause us > heartburn. I think that's a valid concern... but if everything in > common use has both CAS and fetch-and-add, then I think there's > probably no issue here. What I want to know is whether we are going to agree that the set of atomics is going to be CAS plus fetch_and_add plus *nothing else*. Andres seems to envision that those will be a minimal set and then we'll freely use any other atomic op that seems handy as long as we can provide a fallback implementation of it. I agree with Robert that keeping track of the actual cross-platform performance characteristics of such code would be a nightmare. What I want to see is a list of atomic ops that is short enough that we can agree we do not care about PG performance on any platform that hasn't got (fast versions of) all of them. Then we will code and optimize on the basis of having all those ops and no others. We can offer fallback implementations of those ops so that older platforms aren't entirely dead in the water, but they will not be the focus of any performance testing. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers