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