On Mon, Aug 24, 2026 at 1:25 PM Andres Freund <[email protected]> wrote:
> On 2026-08-24 09:16:28 +0100, Alexandre Felipe wrote: > > I also studied the current LWLock the implementation and there is room to > > make the no-contention path faster. Is that something worth doing, > > or is it pointless? > > Hard to say without knowing what you're actually going to propose. Of couse > making the uncontended path faster is attractive, but correctness / > complexity > / contended performance all are also not uninmportant. > Here I include the experiments. Maybe you don't want to use this implementation but it might give you some hints to write a faster version that you like. There are no algorithmic changes. The changes are about 0002 having two distinct paths for LW_EXCLUSIVE and LW_SHARED, the rest is diminishing returns. And also added LWLockReleaseLast, added wrappers as inline functions in lwlock.h that compiles the current code base replacing the calls LWLockAcquire(lock, LW_EXCLUSIVE | LW_SHARED) by the LWLockAcquire(Exclusive|Shared)(lock) 0003 reading the mode from the LWLock state and saving space and time storing it in the held lwlocks array. 0004 well, bring LWLock(Acquire/Release)X external functions that take mode as a parameter (a baseline). 0005 Inlined LWLockAttemptLock and folded the loop, placing a single LWLockAttemptLock at the top of the loop followed by the common logic (previously at the end bottom of the function), then enqueue and continue or wait. Regards, Alexandre
0002-LWLock-fast-paths.patch
Description: Binary data
0004-mode-as-a-dynamic-parameter.patch
Description: Binary data
0001-Benchmark.patch
Description: Binary data
0003-lwlock-Save-only-pointer.patch
Description: Binary data
0005-Inline-attempt-and-fold-acquire-loop.patch
Description: Binary data
