================
@@ -48,7 +48,10 @@ PathMappingList::PathMappingList(const PathMappingList &rhs)
const PathMappingList &PathMappingList::operator=(const PathMappingList &rhs) {
if (this != &rhs) {
- std::scoped_lock<std::recursive_mutex, std::recursive_mutex>
locks(m_mutex, rhs.m_mutex);
+ std::scoped_lock<std::mutex, std::mutex> pairs_locks(m_pairs_mutex,
+ rhs.m_pairs_mutex);
+ std::scoped_lock<std::mutex, std::mutex> callback_locks(
+ m_callback_mutex, rhs.m_callback_mutex);
----------------
JDevlieghere wrote:
Right, it took me a while to convince myself that wouldn't just cause the same
problem. The only way to avoid a deadlock is always acquire the lock in the
same order and because we always acquire the `m_callback_mutex` before doing
callback, and that's the only one that could be locked while acquiring the
`m_pairs_mutex` (i.e. there's no code path besides that and `operator= ` that
acquires both locks), that both mutex are always acquired in order.
https://github.com/llvm/llvm-project/pull/114576
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
