[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:
Depends
depends on SERVER-77213 Move the all transactions-related sta... Backlog
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. 

 

Since the comment dates back to almost a decade ago, and is slightly misleading, we should probably remove it or reconsider if it is possible to guarantee we only unlock resources which have already been locked.

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.

CC jordi.olivares-provencio@mongodb.com

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