[SERVER-78735] Introduce invariant in Locker::unlock that lock must have been previously acquired Created: 06/Jul/23 Updated: 15/Dec/23 |
|
| Status: | Blocked |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Haley Connelly | Assignee: | Backlog - Catalog and Routing |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Catalog and Routing
|
||||||||
| Participants: | |||||||||
| Description |
|
If we can't find the requested resource, LockerImpl:unlock() returns false. However, there is a comment saying it is an invariant violation we try to release a lock not previously required.
We should try to re-introduce the invariant that Locker::unlock must be called on a resource previously locked by the Locker instance. |
| Comments |
| Comment by Kaloian Manassiev [ 07/Jul/23 ] |
|
FYI, the reason we couldn't introduce this invariant is yielding and getMore, whereby we are allowed to run the destructors of auto-getters and scoped locks with the locks underneath actually released. With the acquisitions API we should be able to reintroduce it, but it likely depends on SERVER-77213. I would fix the comment, but also rephrase the ticket to mean "introduce such invariant" and block it on SERVER-77213. |