Skip to content
Commit ec8d2a29 authored by Aleksy Barcz's avatar Aleksy Barcz
Browse files

deadlock in UDIC/UDIM fix continuation

+ follow-up of "fixed deadlock in defined initialization"
+ previous fix fixed the deadlock in one case, but not in the general case, as unfortunately there are other call-traces that lead to the deadlock
+ this fixes a sequence, where thread 1 calls UDIM::AddUserDef (acquires mutex), which calls UDIC::AddUserDef (acquires m_lock); while thread 2 calls PCIC::GetConfig (acquires m_lock), which calls UDIC::AddConfig, which calls UDIM::PopConfig (acquires mutex)
+ the general design flaw is that UDIM can call UDIC and vice versa. This is wrong and especially bug-prone when using locks.
+ this fix should fix the general case. The design flaw remains to be fixed, but now whenever UDIM calls UDIC, it does so without holding mutex (fixed both places in code where I found such a situation). So both locks are held only on the path from UDIC to UDIM and not vice versa.
parent e471e6f7
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment