[SERVER-69461] The behaviour of lock acquisitions differs depending on whether OpContext or Locker is used Created: 06/Sep/22  Updated: 29/Oct/23  Resolved: 27/Sep/23

Status: Closed
Project: Core Server
Component/s: Concurrency
Affects Version/s: None
Fix Version/s: 7.2.0-rc0

Type: Bug Priority: Major - P3
Reporter: Kaloian Manassiev Assignee: Yujin Kang Park
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-78438 acquireCollectionsOrViews should leav... Closed
depends on SERVER-79176 Index build _completeExternalAbort sh... Closed
depends on SERVER-79186 Make createSystemIndexes support inte... Closed
Duplicate
is duplicated by SERVER-69462 Lock acquisitions won't always obey t... Closed
Problem/Incident
Related
is related to SERVER-69462 Lock acquisitions won't always obey t... Closed
is related to SERVER-69523 Allow METADATA and MUTEX locks to be ... Closed
is related to SERVER-69727 Make ResourceLock acquisitions in the... Closed
Assigned Teams:
Storage Execution
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Execution Team 2023-06-12, Execution EMEA Team 2023-06-26, Execution EMEA Team 2023-07-10, Execution EMEA Team 2023-07-24, Execution EMEA Team 2023-08-21, Execution EMEA Team 2023-09-04, Execution EMEA Team 2023-09-18, Execution EMEA Team 2023-10-02
Participants:
Linked BF Score: 146

 Description   

There are multiple lock manager RAII classes which take both OperationContext and Locker (or both) and it looks like there exists at least one case where the behaviour of locking differs based on whether locker is passed directly or not.

For example, if we remove the Locker-only constructor of ResourceLock, this invariant starts getting hit reliably. The condition to check for the invariant doesn't get reached if opCtx is nullptr (which is what happens if we use the locker-only constructor).

Having such differentiation is dangerous and error-prone and we should get rid of it.

Architecturally, the OpContext and the Locker are complementary with each other. The OpContext is necessary for the "OS-like" utilities such as interruption, deadline, the operation's settings, transactional state, etc and the Locker is just the container for the currently-acquired locks.



 Comments   
Comment by Githook User [ 27/Sep/23 ]

Author:

{'name': 'Yu Jin Kang Park', 'email': 'yujin.kang@mongodb.com', 'username': 'ykangpark'}

Message: SERVER-69461 Remove ResourceLock contructor taking Locker*
Branch: master
https://github.com/mongodb/mongo/commit/959ccc81b8ee064976d7949ee430987b1a8eedd5

Comment by Githook User [ 17/Jul/23 ]

Author:

{'name': 'Gregory Noma', 'email': 'gregory.noma@gmail.com', 'username': 'gregorynoma'}

Message: Revert "SERVER-69461 Remove ResourceLock contructor taking Locker*"

This reverts commit fc0cd619e16d8cbdb0a6978cd0f97dcc3f1514ed.
Branch: master
https://github.com/mongodb/mongo/commit/03181c3abac6e751ec4c81c7497f20bf433738fe

Comment by Githook User [ 11/Jul/23 ]

Author:

{'name': 'Yu Jin Kang Park', 'email': 'yujin.kang@mongodb.com', 'username': 'ykangpark'}

Message: SERVER-69461 Remove ResourceLock contructor taking Locker*
Branch: master
https://github.com/mongodb/mongo/commit/fc0cd619e16d8cbdb0a6978cd0f97dcc3f1514ed

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