[SERVER-37682] Do not yield locks in an UninterruptibleLockGuard Created: 19/Oct/18  Updated: 04/Feb/19  Resolved: 29/Oct/18

Status: Closed
Project: Core Server
Component/s: Querying, Replication, Storage
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Judah Schvimer Assignee: Judah Schvimer
Resolution: Won't Fix Votes: 0
Labels: prepare_durability
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-37689 Make recovery from query yield interr... Closed
Operating System: ALL
Sprint: Repl 2018-11-05
Participants:

 Description   

Retryable writes check out a session and also yield locks in an UninterruptibleLockGuard. It is illegal for any operations that check out a session to use an UninterruptibleLockGuard.



 Comments   
Comment by Kaloian Manassiev [ 28/Oct/18 ]

Given that we can't remove yielding altogether and also cannot avoid putting the UninterruptibleLockGuard in the yielding code, should this be closed now?

Comment by Judah Schvimer [ 22/Oct/18 ]

This effectively means that any find/aggregation and etc, which is executed under a logical session won't be able to yield its locks either.

kaloian.manassiev, this ticket was meant to make yielding and its recovery interruptible, not to remove yielding.

Comment by Geert Bosch [ 22/Oct/18 ]

kaloian.manassiev, yielding will generally be required for good performance, in my opinion. Long running operations that do not yield require us to keep around a lot of history. Today that means high cache pressure, as we don't save history information to stable storage. However, even if we do so in the future, reading from historic data is going to be fundamentally more expensive than reading recent data that may be kept in memory.

The other obvious reason we need yielding is to prevent and/or resolve update conflicts. If you're doing an update of a document that has recently been changed, you must yield to be able to read the more recent version of the document and update that (assuming it still matches the update criteria).

Comment by Kaloian Manassiev [ 20/Oct/18 ]

This effectively means that any find/aggregation and etc, which is executed under a logical session won't be able to yield its locks either. I encountered this as part of my changes for SERVER-37244 and filed SERVER-37689, but now that I think about it more I think we might just disallow yielding in sessions (which is as if we disallowed yielding altogether).

david.storch, geert.bosch - do you think it is about time we threw out yielding or there are some use cases that still depend on it? Can you weigh on whether we should do that or implement SERVER-37689? I would be happy to close SERVER-37689 as won't fix.

Generated at Thu Feb 08 04:46:42 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.