[SERVER-60049] Investigate using AtomicLockStats over SingleThreadedLockStats in lock_state.h Created: 17/Sep/21 Updated: 29/Oct/23 Resolved: 07/Oct/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 5.2.0 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Gregory Wlodarek | Assignee: | Gregory Wlodarek |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Sprint: | Execution Team 2021-10-18 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Linked BF Score: | 35 | ||||||||||||||||
| Description |
|
Operations that use the LockerImpl interface for acquiring locks are expected to call the lock/unlock methods from a single thread. A part of locking a lock involves incrementing the lock stats (_stats in lock_state.h). Single-threaded access to this data structure is not enforced as CurOp can access it concurrently for user reporting purposes. To fix TSAN build failures in this area we should investigate using AtomicLockStats over SingleThreadedLockStats. |
| Comments |
| Comment by Githook User [ 07/Oct/21 ] |
|
Author: {'name': 'Gregory Wlodarek', 'email': 'gregory.wlodarek@mongodb.com', 'username': 'GWlodarek'}Message: |
| Comment by Geert Bosch [ 24/Sep/21 ] |
|
This was quite perf sensitive code, and we move from atomics to this structure around 3.0, as it showed up as perf bottleneck. We have gotten so much slower elsewhere that it may not make a big difference anymore, or the fact that this is still effectively per thread may make atomics not a big deal, as opposed to the earlier direct updates of the same atomic objects by multiple threads. |