[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: |
|
||||||||
| 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. |