aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/CodeGen/CodeGenModule.cpp
diff options
context:
space:
mode:
authorJonas Devlieghere <jonas@devlieghere.com>2024-03-27 16:37:00 -0700
committerGitHub <noreply@github.com>2024-03-27 16:37:00 -0700
commitb76fd1eddbafaa02a533245d574048c5ad9e38fa (patch)
treea07cb34dc29f6cea46e1d266f42258cfbc355622 /clang/lib/CodeGen/CodeGenModule.cpp
parent14ba782a87e16e9e15460a51f50e67e2744c26d9 (diff)
downloadllvm-b76fd1eddbafaa02a533245d574048c5ad9e38fa.zip
llvm-b76fd1eddbafaa02a533245d574048c5ad9e38fa.tar.gz
llvm-b76fd1eddbafaa02a533245d574048c5ad9e38fa.tar.bz2
[lldb] Avoid deadlock by unlocking before invoking callbacks (#86888)
Avoid deadlocks in the Alarm class by releasing the lock before invoking callbacks. This deadlock manifested itself in the ProgressManager: 1. On the main thread, the ProgressManager acquires its lock in ProgressManager::Decrement and calls Alarm::Create. 2. On the main thread, the Alarm acquires its lock in Alarm::Create. 3. On the alarm thread, the Alarm acquires its lock after waiting on the condition variable and calls ProgressManager::Expire. 4. On the alarm thread, the ProgressManager acquires its lock in ProgressManager::Expire. Note how the two threads are acquiring the locks in different orders. Deadlocks can be avoided by always acquiring locks in the same order, but since the two mutexes here are private implementation details, belong to different classes, that's not straightforward. Luckily, we don't need to have the Alarm mutex locked when invoking the callbacks. That exactly how this patch solves the issue.
Diffstat (limited to 'clang/lib/CodeGen/CodeGenModule.cpp')
0 files changed, 0 insertions, 0 deletions