]> git.ipfire.org Git - thirdparty/haproxy.git/commit
MEDIUM: threads: keep history of taken locks with DEBUG_THREAD > 0
authorWilly Tarreau <w@1wt.eu>
Mon, 28 Apr 2025 07:42:58 +0000 (09:42 +0200)
committerWilly Tarreau <w@1wt.eu>
Mon, 28 Apr 2025 14:50:34 +0000 (16:50 +0200)
commitb8a1c2380b995841e6a8f9ef94dd534d0f83dea7
treea8404406fbb1fe94654d66f9f1cbfcd3e72d7a38
parent23371b3e7cd2a4fceb828ae50e43681cc44add66
MEDIUM: threads: keep history of taken locks with DEBUG_THREAD > 0

by only storing a word in each thread context, we can keep the history
of all taken/dropped locks by label. This is expected to be very cheap
and to permit to store up to 8 consecutive lock operations in 64 bits.
That should significantly help detect recursive locks as well as figure
what thread was likely to hinder another one waiting for a lock.

For now we only store the final state of the lock, we don't store the
attempt to get it. It's just a matter of space since we already need
4 ops (rd,sk,wr,un) which take 2 bits, leaving max 64 labels. We're
already around 45. We could also multiply by 5 and still keep 8 bits
total per lock, that would limit us to 51 locks max. It seems that
most of the time if we get a watchdog panic, anyway the victim thread
will be perfectly located so that we don't need a specific value for
this. Another benefit is that we perform a single memory write per
lock.
include/haproxy/thread.h
include/haproxy/tinfo-t.h