CollectionShardingState::getCriticalSectionSignal does not take or enforce any locks, and ShardingMigrationCriticalSection::getSignal does not do any synchronization either.

When entering the critical section in migration, we use an X lock, but when exiting (which calls .reset() on the signal), we only use an IX lock.

Furthermore, in setShardVersion, when we call getCriticalSectionSignal we're only holding an IS lock on the collection which does not conflict with the IX lock held in exitCriticalSection, so there's no synchronization on reading/writing the shared_ptr for the critical section signal. The same is true in _flushRoutingTableCacheUpdates.

Fortunately in the normal path for inspecting the critical section we use a shared lock on the CSR which conflicts with the exclusive lock taken on the CSR when we exit the critical section.