[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:
Depends
is depended on by SERVER-69143 CursorManager no longer needs to hand... Open
Duplicate
is duplicated by SERVER-68874 Consider making waitAfterPinningCurso... Closed
Related
related to SERVER-35321 Make renameCollection uninterruptible Closed
is related to SERVER-69506 An InterruptibleLockGuard should be p... Backlog
is related to SERVER-69406 Place InterruptibleLockGuards in the ... Closed
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: SERVER-69059 Create an InterruptibleLockGuard to place in ClientCursorPin to ensure read operations are interruptible
Branch: master
https://github.com/mongodb/mongo/commit/97cdfef9e4f74918176f1916bc53ada8f9f66868

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:

  • Every code path should in fact be interruptible and in that sense, such thing as the InterruptibleLockGuard is equivalent to saying "don't add any new UninterruptibleLockGuard usages". So I'd rather we just rename UILG to something really ugly like UILG_Do_Not_Add_New_Usages and put a big comment of why and we try little by little to remove them.
  • There exist legitimate cases that need to block interruptions, such as taking level-0 resource mutexes (sharding uses that) and if it happens that we need to add a sharding service invocation on a path that has thing placed somewhere it will invariant, even though it is harmless.
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?

Generated at Thu Feb 08 06:12:28 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.