1. 04 Feb, 2020 1 commit
    • Aleksy Barcz's avatar
      deadlock in UDIC/UDIM fix continuation · ec8d2a29
      Aleksy Barcz authored
      + 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.
      ec8d2a29
  2. 14 Feb, 2019 1 commit
  3. 23 Jan, 2019 2 commits
    • Aleksy Barcz's avatar
      defined: fixed deallocation · 25bbec8c
      Aleksy Barcz authored
      + added missing destructor, freeing memory allocated with new()
      25bbec8c
    • Aleksy Barcz's avatar
      fixed deadlock in defined initialization · c5e0c414
      Aleksy Barcz authored
      + ParamCachingIPKContainer::GetConfig() would first acquire-unique m_lock, then via UserDefinedIPKContainer::AddConfig() (inheritance) would try to acquire UserDefinedIPKManager::mutex
      + in another thread UserDefinedIPKManager::AddUserDefined() would first acquire-unique UDIM::mutex, then via UDIC::AddUserDefined() would try to acquire m_lock
      + now, UDIM::AddUserDefined() won't hold UDIM::mutex when accessing UDIC
      + also, removed Lock() and Release() methods which were a violation of RAII
      c5e0c414
  4. 16 Jul, 2018 1 commit