zturner added a comment. Seems like the high level problem is that the entity which acquires the mutex is not the same as the entity which decides how data gets into the Module. For example, we call `SymbolVendor::FindFunctions` and expect that someone is going to somehow get some functions into the Module. But it doesn't anticipate that that someone decides it wants to do it in a multi-threaded fashion. I think as a general principle, when you have this kind of lazy access pattern, you need to clearly separate the responsibilities. The entity that acquires the lock needs to be the same entity that updates the state.
In other words, something like this: // Not locked auto Functions = m_sym_file_ap->FindFunctions(...); // Now grab the lock and update the Module std::lock_guard<std::recursive_mutex> guard(module_sp->GetMutex()); module_sp->AddFunctions(Functions); https://reviews.llvm.org/D41909 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
