Re: better atomics - v0.6
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Heikki Linnakangas <hlinnakangas@vmware.com>
Cc: Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>,
Amit Kapila <amit.kapila16@gmail.com>, Peter Geoghegan <pg@heroku.com>,
Pg Hackers <pgsql-hackers@postgresql.org>, Ants Aasma <ants@cybertec.at>
Date: 2014-09-24T18:28:18Z
Lists: pgsql-hackers
Heikki Linnakangas <hlinnakangas@vmware.com> writes: > On 09/24/2014 07:57 PM, Andres Freund wrote: >> On 2014-09-24 12:44:09 -0400, Tom Lane wrote: >>> I think the question is more like "what in the world happened to confining >>> ourselves to a small set of atomics". >> I fail to see why the existance of a wrapper around compare-exchange >> (which is one of the primitives we'd agreed upon) runs counter to >> the agreement that we'll only rely on a limited number of atomics on the >> hardware level? > It might be a useful function, but if there's no hardware implementation > for it, it doesn't belong in atomics.h. We don't want to turn it into a > general library of useful little functions. Note that the spinlock code separates s_lock.h (hardware implementations) from spin.h (a hardware-independent abstraction layer). Perhaps there's room for a similar separation here. I tend to agree with Heikki that wrappers around compare-exchange ought not be conflated with compare-exchange itself, even if there might theoretically be architectures where the wrapper function could be implemented directly. regards, tom lane
Commits
-
Avoid the use of a separate spinlock to protect a LWLock's wait queue.
- 008608b9d510 9.6.0 cited
-
Improve LWLock scalability.
- ab5194e6f617 9.5.0 cited
-
Reduce the number of semaphores used under --disable-spinlocks.
- daa7527afc22 9.4.0 cited
-
Alter the configure script to fail immediately if the C compiler does not
- d15cb38dec01 9.0.0 cited