[SERVER-69059] Create an InterruptibleLockGuard to place in ClientCursorPin to ensure read operations are interruptible Created: 22/Aug/22 Updated: 29/Oct/23 Resolved: 02/Sep/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 6.2.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Dianna Hohensee (Inactive) | Assignee: | Dianna Hohensee (Inactive) |
| 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 2022-09-05 | ||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||
| Description |
|
An InterruptibleLockGuard will ensure that there is no active UninterruptibleLockGuard on the stack. Since ClientCursors are holding storage cursors now, we need to ensure there's never a deadlock between replication rollback (holding a global X lock) and interrupted read operations trying to acquire a lock while a ClientCursor is already pinned (pinning occurs without a lock). |
| Comments |
| Comment by Githook User [ 02/Sep/22 ] |
|
Author: {'name': 'Dianna Hohensee', 'email': 'dianna.hohensee@mongodb.com', 'username': 'DiannaHohensee'}Message: |
| Comment by Kaloian Manassiev [ 30/Aug/22 ] |
|
Sorry for the delayed reply. I don't think there is any use case which is on the CRUD paths that requires the ability to block interrupts, so you are safe from that point of view. |
| Comment by Dianna Hohensee (Inactive) [ 24/Aug/22 ] |
|
Yes, I think there are cases where we need the ULG today. Someday hopefully we can find other solutions, but not any time soon. I'm interested specifically in putting InterruptibleLockGuards on the getMore command path – make ClientCursorPins hold an InterruptibleLockGuard instance. kaloian.manassiev@mongodb.com do you think there will be sharding related uses on the getMore command path? I don't have any intentions of using the new Guard more widely than that. I agree with your reasoning of stopping new additions and phasing out the existing uses. |
| Comment by Kaloian Manassiev [ 24/Aug/22 ] |
|
Ah ok, thanks for the explanation - so it is not about "canceling-out" an existing UILG, but rather to mark that a code path should never be blocking interruptions. Sorry for jumping on this, but I don't think we should be introducing such a concept and here is the reasoning:
|
| Comment by Dianna Hohensee (Inactive) [ 23/Aug/22 ] |
|
Yes, an InterruptibleLockGuard on the stack will ensure both that (1) there is no higher level code holding an UninterruptibleLockGuard and (2) that no lower level code takes an UninterruptibleLockGuard. I should have that in the description, thanks : ) |
| Comment by Kaloian Manassiev [ 23/Aug/22 ] |
|
What is InterruptibleLockGuard? Is that the archnemesis of UninterruptibleLockGuard? Is it supposed to be used in order to counteract a previously placed UILG somewhere up the stack? |