-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Fully Compatible
-
ALL
-
QE 2022-10-17
-
129
It appears that cursorsTimedOut() and incrementCursorsTimedOut can be called on different threads, and there is no lock
https://github.com/10gen/mongo/blob/7b470a0d23c5a0e86f398082f88e1f136837d320/src/mongo/s/query/cluster_cursor_manager.h#L518-L524
Here's the writer:
https://github.com/10agen/mongo/blob/7b470a0d23c5a0e86f398082f88e1f136837d320/src/mongo/s/query/cluster_cursor_cleanup_job.cpp#L65-L66
Here's the reader:
https://github.com/10gen/mongo/blob/7b470a0d23c5a0e86f398082f88e1f136837d320/src/mongo/s/cluster_cursor_stats.cpp#L48-L49
In practice, this race is unlikely, but it's worth fixing. Also, it's creating a lot of noise on TSAN builds (e.g., BF-26555). Probably just using a std::atomic for _cursorsTimedOut will solve the issue.
- related to
-
SERVER-70486 Reduce the number of mutex locks in ClusterCursorManager
- Backlog