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

  1. Avoid the use of a separate spinlock to protect a LWLock's wait queue.

  2. Improve LWLock scalability.

  3. Reduce the number of semaphores used under --disable-spinlocks.

  4. Alter the configure script to fail immediately if the C compiler does not