aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Bitcode
diff options
context:
space:
mode:
authorjimingham <jingham@apple.com>2024-11-18 13:23:17 -0800
committerGitHub <noreply@github.com>2024-11-18 13:23:17 -0800
commitb42a81631491571c4b78d095917ebdddee69b04f (patch)
tree644c0717d0d8679bfa00e9da7995a2310aceb9a1 /llvm/lib/Bitcode
parentcde4ae789e4a2f408d06d2b0045cca22c201c47b (diff)
downloadllvm-b42a81631491571c4b78d095917ebdddee69b04f.zip
llvm-b42a81631491571c4b78d095917ebdddee69b04f.tar.gz
llvm-b42a81631491571c4b78d095917ebdddee69b04f.tar.bz2
Convert ThreadPlanStack's mutex to a shared mutex. (#116438)
I have some reports of A/B inversion deadlocks between the ThreadPlanStack and the StackFrameList accesses. There's a fair bit of reasonable code in lldb that does "While accessing the ThreadPlanStack, look at that threads's StackFrameList", and also plenty of "While accessing the ThreadPlanStack, look at the StackFrameList." In all the cases I've seen so far, there was at most one of the locks taken that were trying to mutate the list, the other three were just reading. So we could solve the deadlock by converting the two mutexes over to shared mutexes. This patch is the easy part, the ThreadPlanStack mutex. The tricky part was because these were originally recursive mutexes, and recursive access to shared mutexes is undefined behavior according to the C++ standard, I had to add a couple NoLock variants to make sure it didn't get used recursively. Then since the only remaining calls are out to ThreadPlans and ThreadPlans don't have access to their containing ThreadPlanStack, converting this to a non-recursive lock should be safe.
Diffstat (limited to 'llvm/lib/Bitcode')
0 files changed, 0 insertions, 0 deletions