[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:
Depends
Problem/Incident
Related
related to SERVER-56281 Investigate data race between curOp a... Closed
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: SERVER-60049 Use AtomicLockStats over SingleThreadedLockStats in the locker
Branch: master
https://github.com/mongodb/mongo/commit/acdb34256ebc4c3e168fa0c546c38901b6535b19

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.

Generated at Thu Feb 08 05:48:49 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.