[all-commits] [llvm/llvm-project] 186fac: Convert the StackFrameList mutex to a shared mutex...

[jimingham via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 186fac33d08b34be494caa58fe63972f69c6d6ab
      https://github.com/llvm/llvm-project/commit/186fac33d08b34be494caa58fe63972f69c6d6ab
  Author: jimingham <jingham at apple.com>
  Date:   2024-12-12 (Thu, 12 Dec 2024)

  Changed paths:
    M lldb/include/lldb/Target/StackFrameList.h
    M lldb/source/Target/StackFrameList.cpp
    M lldb/source/Target/Thread.cpp
    M lldb/test/API/api/multithreaded/TestMultithreaded.py
    A lldb/test/API/api/multithreaded/deep_stack.cpp
    A lldb/test/API/api/multithreaded/test_concurrent_unwind.cpp.template

  Log Message:
  -----------
  Convert the StackFrameList mutex to a shared mutex. (#117252)

In fact, there's only one public API in StackFrameList that changes
 the list explicitly.  The rest only change the list if you happen to
ask for more frames than lldb has currently fetched and that 
always adds frames "behind the user's back".  So we were
much more prone to deadlocking than we needed to be.

This patch uses a shared_mutex instead, and when we have to add more
frames (in GetFramesUpTo) we switches to exclusive long enough to add
the frames, then goes back to shared.
    
Most of the work here was actually getting the stack frame list locking
to not
require a recursive mutex (shared mutexes aren't recursive). 
    
I also added a test that has 5 threads progressively asking for more
frames simultaneously to make sure we get back valid frames and don't
deadlock.



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