[SERVER-74781] Investigate behavior of ScopedAdmissionPriorityForLock when locker is swapped Created: 13/Mar/23  Updated: 12/May/23  Resolved: 12/May/23

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

Type: Task Priority: Major - P3
Reporter: Gregory Noma Assignee: Haley Connelly
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-74544 Move SetAdmissionPriorityForLock from... Closed
is related to SERVER-77084 Investigate swapLockState() usage Closed
Assigned Teams:
Storage Execution
Backwards Compatibility: Fully Compatible
Sprint: Execution Team 2023-05-01, Execution Team 2023-05-15
Participants:

 Description   

ScopedAdmissionPriorityForLock stores a pointer to the lock state (which is typical for locker-related RAII types), but in some cases the locker gets swapped out with another one.



 Comments   
Comment by Haley Connelly [ 12/May/23 ]

The RAII-style pattern used for ScopedAdmissionPriorityForLock, which introduces scoped modifications to part of the Locker state, is a common pattern in the codebase. However, the pattern assumes the Locker in use at the start of the scope stays alive for the remainder of the scope.

Closing this ticket in favor of SERVER-77084, which will investigate the usage of swapLockState() in our codebase. 

Comment by Haley Connelly [ 12/May/23 ]

For clarification, it wasn't clear it was unsafe to use the ScopedAdmissionPriorityForLock RAII type in OplogApplierImpl::_applyOplogBatch until tests began to fail during development.

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