[SERVER-59800] Add a flag to the lock-free collection helpers to optionally take the RSTL intent lock Created: 04/Sep/21  Updated: 04/Feb/22  Resolved: 04/Feb/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: Dianna Hohensee (Inactive)
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-59719 shardsvr{Commit, Abort}ReshardCollect... Closed
Sprint: Execution Team 2021-11-01, Execution Team 2022-02-21
Participants:

 Description   

I think this would be good temporary measure to smooth out transitioning to lock-free helpers, and away from falling back on db+coll locks. 

User read operations would want to avoid stalling, and being stalled by, replication state change. However, internal operations and reads done as part of greater commands may not be in a good position yet to eliminate dependencies on repl state change interrupts. Removing the RSTL lock from such operations cause them to behave unexpectedly because normally they would either hold repl state change back until finished or would wait until repl state change finished, ensuring that their interrupt flag has been set by the time lock acquisition finishes, and lock acquisition throws on opCtx interrupts.

I think the system as a whole should move away from depending on RSTL locks for becoming aware of stepdown, but we do not currently have such a system, yet.



 Comments   
Comment by Dianna Hohensee (Inactive) [ 04/Feb/22 ]

On a fresh look, I'm not sure this makes sense. We've added AutoGet*MaybeLockFree to several read-only commands. Internal operations using lock-free therefore must be going through the command interface: we can't change the commands to take the RSTL lock.

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