[all-commits] [llvm/llvm-project] b42a81: Convert ThreadPlanStack's mutex to a shared mutex....

[jimingham via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: b42a81631491571c4b78d095917ebdddee69b04f
      https://github.com/llvm/llvm-project/commit/b42a81631491571c4b78d095917ebdddee69b04f
  Author: jimingham <jingham at apple.com>
  Date:   2024-11-18 (Mon, 18 Nov 2024)

  Changed paths:
    M lldb/include/lldb/Target/ThreadPlanStack.h
    M lldb/source/Target/ThreadPlanStack.cpp

  Log Message:
  -----------
  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.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications