On 20.05.2013 23:01, Bruce Momjian wrote:
On Thu, May 16, 2013 at 12:08:40PM -0400, Tom Lane wrote:
Stephen Frost<sfr...@snowman.net> writes:
Isn't this the same issue which has prompted multiple people to propose
(sometimes with code, as I recall) to rip out our internal spinlock
system and replace it with kernel-backed calls which do it better,
specifically by dealing with issues like the above? Have you seen those
threads in the past? Any thoughts about moving in that direction?
All of the proposals of that sort that I've seen had a flavor of
"my OS is the only one that matters". While I don't object to
platform-dependent implementations of spinlocks as such, they're not
much of a cure for a generic performance issue.
Uh, is this an x86-64-only optimization? Seems so.
All modern architectures have an atomic compare-and-swap instruction (or
something more powerful that can be used to implement it). That includes
x86, x86-64, ARM, PowerPC, among others.
There are some differences in how wide values can be swapped with it;
386 only supported 32-bit, until Pentium, which added a 64-bit variant.
I used the 64-bit variant in the patch, but for lwlocks, we could
actually get away with the 32-bit variant if we packed the booleans and
the shared lock counter more tightly.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
