[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: |
|
||||||||||||
| 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. |