Robert Haas <robertmhaas@gmail.com> writes:
On Thu, Jan 4, 2024 at 10:22 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
We should be making an effort to ban coding patterns like
"return with spinlock still held", because they're just too prone
to errors similar to this one.
I agree that we don't want to add overhead, and also about how
spinlocks should be used, but I dispute "easily detectable
statically." I mean, if you or I look at some code that uses a
spinlock, we'll know whether the pattern that you mention is being
followed or not, modulo differences of opinion in debatable cases. But
you and I cannot be there to look at all the code all the time. If we
had a static checking tool that was run as part of every build, or in
the buildfarm, or by cfbot, or somewhere else that raised the alarm if
this rule was violated, then we could claim to be effectively
enforcing this rule.
I was indeed suggesting that maybe we could find a way to detect
such things automatically.  While I've not been paying close
attention, I recall there's been some discussions of using LLVM/clang
infrastructure for customized static analysis, so maybe it'd be
possible without an undue amount of effort.

FWIW, the lackey[1] tool in Valgrind is able to do some kinds of instruction counting, so it might be possible to measure how many instructions are actualyl being executed while holding a spinlock. Might be easier than code analysis.

Another possibility might be using the CPUs timestamp counter.

1: https://valgrind.org/docs/manual/lk-manual.html

-- 
Jim Nasby, Data Architect, Austin TX