Skip to content
Browse files
Improve LWLock scalability.
The old LWLock implementation had the problem that concurrent lock
acquisitions required exclusively acquiring a spinlock. Often that
could lead to acquirers waiting behind the spinlock, even if the
actual LWLock was free.

The new implementation doesn't acquire the spinlock when acquiring the
lock itself. Instead the new atomic operations are used to atomically
manipulate the state. Only the waitqueue, used solely in the slow
path, is still protected by the spinlock. Check lwlock.c's header for
an explanation about the used algorithm.

For some common workloads on larger machines this can yield
significant performance improvements. Particularly in read mostly

Reviewed-By: Amit Kapila and Robert Haas
Author: Andres Freund

  • Loading branch information
anarazel committed Dec 25, 2014
1 parent 7882c3b commit ab5194e6f617a9a9e7aadb3dd1cee948a42d0755
Showing with 653 additions and 302 deletions.
  1. +638 −293 src/backend/storage/lmgr/lwlock.c
  2. +15 −9 src/include/storage/lwlock.h

2 comments on commit ab5194e


This comment has been minimized.

Copy link

@ender233 ender233 replied Apr 18, 2019

hello. still have some question.

  1. LWLockAttemptLock will spin in atomic com_and_swap, and SpinLockAcquire will spin in atomic test_and_set, so is any differences ?
  2. could you please shared the benchmark for it?



This comment has been minimized.

Copy link
Contributor Author

@anarazel anarazel replied May 22, 2019

@ender233 This is a five year old commit? There's a lot of discussion, including benchmarks, below

And yes, it's a fundamental difference. It's not the spinning itself that's the big problem it's that the spinlock was held while acquiring a shared lock, even when there was no conflicting lwlock holder. Whereas the new approach acquires uncontended lock in a single atomic op (or a few retries), without holding any locks preventing other sessions from acquiring the lock in shared mode.

Please sign in to comment.