Re: Better LWLocks with compare-and-swap (9.4)
От | Heikki Linnakangas |
---|---|
Тема | Re: Better LWLocks with compare-and-swap (9.4) |
Дата | |
Msg-id | 519A84A9.2050703@vmware.com обсуждение исходный текст |
Ответ на | Re: Better LWLocks with compare-and-swap (9.4) (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: Better LWLocks with compare-and-swap (9.4)
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: