Fix TSAN lock inversion in VirtualEventBase and FiberManagerMap
Summary: There is a lock inversion between VirtualEventBase and the fibers library: 1. During program shutdown, `GlobalCache::getImpl` acquires its `mutex_`, then it calls `VirtualEventBase::runOnDestruction` which acquires the SharedMutex on `onDestructionCallbacks_` 2. During normal program execution, `VirtualEventBase::destroyImpl()` acquires the `onDestructionCallbacks_` lock and then invokes the user-supplied callbacks, which will invoke `GlobalCache::eraseImpl` and acquire `mutex_` The reason for this lock inversion is because in step 2, we are holding a mutex while invoking user-supplied callbacks. The fix is to NOT hold the lock while we invoke these callbacks. Reviewed By: andriigrynenko Differential Revision: D9797816 fbshipit-source-id: 861a915f22138f0c8d3f8bca4d7bf4b9a0aa3d26
Showing
Please register or sign in to comment