Background

Recently, the CollectionShardingState (CSS) and CollectionShardingRuntime (CSR) received a new synchronization module – the CollectionShardingRuntimeLock (CSRLock). The CSRLock is a ResourceLock meant to be used as a fancier std::mutex. It was built in order to protect lifetime access to pointers and internal structures placed upon the CSS/CSR. Users of the CSS/CSR's internal structures would take the CSRLock when accessing corresponding pointers. The CSRLock would stay in scope until these pointers do not need to be used any longer.

Problem

The CSRLock was built with a key assumption that is shared with std::mutex – we are never to do I/O or network calls while we are inside the locking mechanism.

In the MigrationChunkCloner, a CSR sub-structure, we perform I/O operations. If we are doing this under the CSRLock, this can cause locking issues with other parts of the database system. The linked BF is an example of such an issue.

Solution

We'd still like to protect the lifetime of the MigrationChunkCloner, but do not want to perform I/O operations under the lock. Accordingly, we will change the MigrationChunkCloner from a raw pointer to a shared pointer. This will prevent the object from going out of scope while references to the object exist. Since shared pointers are not thread safe, we will still use the CSRLock to safeguard the creation of additional references.