On 20.05.2013 23:01, Bruce Momjian wrote:
> On Thu, May 16, 2013 at 12:08:40PM -0400, Tom Lane wrote:
>> Stephen Frost<sfrost@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
