[SERVER-33316] Remove limit on number of locks a single operation can take Created: 13/Feb/18  Updated: 29/Oct/23  Resolved: 22/Mar/18

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

Type: Task Priority: Major - P3
Reporter: Spencer Brody (Inactive) Assignee: Dianna Hohensee (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-34008 ensure LockManager complexity is not ... Closed
Backwards Compatibility: Fully Compatible
Sprint: Storage NYC 2018-03-26, Storage NYC 2018-03-12
Participants:

 Comments   
Comment by Githook User [ 22/Mar/18 ]

Author:

{'email': 'dianna.hohensee@10gen.com', 'name': 'Dianna Hohensee', 'username': 'DiannaHohensee'}

Message: SERVER-33316 Remove limit on number of locks a single operation can take

(Replaces the pre-allocated array in FastMapNoAlloc with a dynamic deque)
Branch: master
https://github.com/mongodb/mongo/commit/379044733ab55adf136e7cbbff40a4b6b3b80931

Comment by Dianna Hohensee (Inactive) [ 14/Mar/18 ]

Plan: eliminate the pre-allocated size map of locks (FastMapNoAlloc). Replacing with plain vector of locks, pre-allocated with 16 entries, which can dynamically increase as needed for transactions.

Update: that didn't work, because the LockManager maintains a list of pointers to the LockRequests held by the map of locks. This requires the map data structure to never invalidate pointers to its data: a vector will invalidate memory. Instead, we're swapping FastMapNoAlloc's array with a deque, which can add memory without invalidating pointers/references.

Generated at Thu Feb 08 04:33:00 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.