-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Catalog and Routing
-
3
SERVER-68868 intends to remove UninterruptipleLockGuard uses where possible, from its description:
Uses of UninterruptibleLockGuard indicate places in the code that do not comply with MongoDB's requirement that all operations be interruptible at places where they block to wait for resources. Every one of them is a potential future deadlock, and adds complexity to other parts of the codebase. We should reimplement codepaths that depend on UninterruptibleLockGuard so as to be interruptible.
The work has been split for the different teams in server, this one being for Sharding.
SERVER-68867 introduced a linter rule to add friction when adding new UninterruptipleLockGuard instances, and commented existing ones with NOLINT, while also adding a TODO with the corresponding server team ticket if an instance was found to not have a comment explaining why its use is warranted.
We should either add a comment justifying the use of UninterruptibleLockGuard or fix the code to remove its use.
You may search for "TODO (SERVER-71444)", as of this writing there are 26 instances:
https://github.com/10gen/mongo/blob/34ac49477b87e183637f68cda828ecff8b393c64/src/mongo/db/s/collection_sharding_runtime.cpp#L581
https://github.com/10gen/mongo/blob/34ac49477b87e183637f68cda828ecff8b393c64/src/mongo/db/s/create_collection_coordinator.cpp#L1295
https://github.com/10gen/mongo/blob/34ac49477b87e183637f68cda828ecff8b393c64/src/mongo/db/s/drop_database_coordinator.cpp#L167
...
- is depended on by
-
SERVER-34951 LockerImpl should invariant against active UninterruptibleLockGuard usage when _maxLockTimeout is set
-
- Blocked
-
-
-
- Blocked
-
- is related to
-
SERVER-73218 Deadlock among RecoverRefreshThread, index build, step down, and prepared transaction
-
- Closed
-