This was attempted in SERVER-51319. However, there are existing interface obstructions wherein const CSS and DSS instances are not accepted and accommodation must be made: for example, the CSSLock related code interface needs expansion to accept const instances. Currently the lock-free read access functions are called DSS/CSS::getSharedForLockFreeReads(): they should return a const object.

This would prevent ostensible readers from running CSS functions that may modify the CSS or other sub-state, which is not currently protected against. Sharding may want to consider changes to the CSS and/or DSS classes and subsystems such that there can be const readers and non-const writers such that readers will not be allowed/able to do something they should not by accident.

-----------------------------------------------------------------------------

Some context-y notes:

• Query has a use case for doing an aggregation on a view namespace wherein they must check whether the underlying collection is sharded or not — an optimization to reduce round trips between mongos and shard. Aggregation is running lock-free, so I recommended using CSS::getSharedForLockFreeReads() that bypasses the collection lock requirements for lock-free read operations. It seems likely that we will have an increasing need to access the CSS without collection locks, especially down the line when Execution runs more projects to remove locks from more operations.
• The DatabaseShardingState and CollectionShardingState classes are considered global and unversioned state, I believe, merely accessors for various sharding state. Therefore, it would be best to be able to safely fetch versioned state THROUGH the DSS and CSS objects, to then stash for a lock-free read operation to use until finished.
  • An alternative would be to make these classes copy-on-write, so a lock-free read can grab a versioned instance of the CSS or DSS, but that doesn’t seem desirable from past conversations.
  • As a note, the execution layer Collection class is copy-on-write and can have several Collection instances for a single collection. Furthermore, a Collection instance can have versioned decorations OR unversioned shared decorations via decorating the ShardCollectionDecorations that exists as shared state across all Collection instances for a single collection.