[SERVER-54403] The paradigm of acquiring DSSLocks and CSSLocks AFTER fetching the DSS or CSS under a database/collection level lock doesn't work in a lock-free read world Created: 08/Feb/21  Updated: 04/Jul/23  Resolved: 04/Jul/23

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

Type: Improvement Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: [DO NOT USE] Backlog - Sharding EMEA
Resolution: Duplicate Votes: 0
Labels: PM-2144-Milestone-0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
Problem/Incident
is caused by SERVER-53257 Determine whether we need const Colle... Closed
Assigned Teams:
Sharding EMEA
Participants:

 Description   

DatabaseShardingState and CollectionShardingState use DSSLock and CSSLock mutex RAII types that can only be accessed AFTER the DSS or CSS is fetched. A collection or database level-lock currently protects the DSS::get() and CSS::get() methods. We will not have coll and db locks in the not too distant future, so these expectations should change. Either DSS and CSS should always be safe to access without lock or mutex – the current implementation is, but not officially –, or the DSSLock and CSSLock concepts need to work somehow before fetching the DSS or CSS. (currently the DSS/CSSLock types lock the mutex IN the DSS/CSS).

We already bypass locking requirements via special DSS/CSS::getSharedForLockFreeReads() getter functions, currently only used by lock-free read supporting operations (find,getMore,count,distinct,mapReduce).



 Comments   
Comment by Jordi Serra Torrens [ 04/Jul/23 ]

This is exactly what PM-2144 addresses.

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