3 Commits

Author	SHA1	Message	Date
Valentin Shergin	757518edba	Fabric: ShadowTreeRegistry::get was renamed to ShadowTreeRegistry::visit ... Summary: Trivial. The name `visit` expresss intent more clearly and fits C++17 `std::visit` pattern. Reviewed By: mdvacca Differential Revision: D13269744 fbshipit-source-id: 6aa6569c58aa66673e3f3a1662390a74290b8e01	2018-11-30 17:29:31 -08:00
Valentin Shergin	d150cbc298	Fabric: Using RW-like shared lock in ShadowTreeRegistry ... Summary: `ShadowTree` class is already thread-safe, so we don't need to (we should not) guard concurent access to it. We should guard concurrent write-access to the collection of them though. Note that unordered_map is "thread-compatible" collection, so concurrent reading access is okay. Reviewed By: mdvacca Differential Revision: D13269745 fbshipit-source-id: 4779626018da0e42b81a835e538f6c1d1a8e25f7	2018-11-30 17:29:31 -08:00
Valentin Shergin	b4fa1fa0c6	Fabric: Introducing ShadowTreeRegistry ... Summary: Why do we need a dedicated registry class? * We need to simplify registry-related logic in Scheduler. * We need to couple threading aspect of the registry with the registry itself, otherwise it's not clear why exactly we acquire the mutex. We also should not acquire the mutex in a per-method way (as we did before), because it's incorrect and misleading (only lines that access the registry should by protected). * We need to have a way to share the registry with other classes (e.g. UIManager) without passing a reference to the whole Scheduler. Reviewed By: mdvacca Differential Revision: D13036550 fbshipit-source-id: 644da910e823666c586834a3da2b4cdcb90eebb2	2018-11-21 17:16:48 -08:00