Throwing away unnecessary spin-locks - Mailing list pgsql-hackers

From Alexandre Felipe
Subject Throwing away unnecessary spin-locks
Date
Msg-id CAE8JnxPcmZVDkf39Pa=uBGcVacsm6OkGxYigp6Znxu=Z3_DE7w@mail.gmail.com
Whole thread
Responses Re: Throwing away unnecessary spin-locks
List pgsql-hackers
Hi All,

Please try, if you want
$ grep -A 2 -rn SpinLockAcquire src/backend | grep SpinLockRelease -B 2

Story
=====
A common pattern that I have been repeatedly warned against is using
spin-locks unnecessarily. I was surprised to see in checkpointer.c
FirstCallSinceLastCheckpoint.

int new_done;
SpinLockAcquire(&CheckpointerShmem->ckpt_lck);
new_done = CheckpointerShmem->ckpt_done;
SpinLockRelease(&CheckpointerShmem->ckpt_lck);

I think could certainly be replaced by something like

+ pg_compiler_barrier()
+ new_done = CheckpointerShmem->ckpt_done;
+ pg_compiler_barrier()

Grepping the codebase we get
105 matches, in 26 files.

One interesting case is xlog.c that uses the lock to protect 64-bit assignments
I saw conversations about pg_atomic_u64 for that, but then in 32-bit platforms
we get this weird 3-field structure everywhere.


Regards,
Alexandre




pgsql-hackers by date:

Previous
From: Jelte Fennema-Nio
Date:
Subject: Re: Commitfest PG20-2 is now closed
Next
From: Alexander Lakhin
Date:
Subject: Re: Improving tracking/processing of buildfarm test failures