[SERVER-47564] Add concurrency control to setting and unsetting the ShardingMigrationCriticalSection flag that does not rely upon collection locks Created: 15/Apr/20  Updated: 06/Dec/22  Resolved: 15/Apr/20

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

Type: Task Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: Backlog - Storage Execution Team
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-47563 Add concurrency control to the Collec... Closed
Assigned Teams:
Storage Execution
Participants:

 Description   

The ShardingMigrationCriticalSection for each collection has no concurrency control itself. It depends upon the CollectionShardingRuntime to provide concurrency control. The two ShardingMigrationCriticalSection::entering* functions expect a collection X lock, the ShardingMigrationCriticalSection::exit* function expects a IX lock, and ShardingMigrationCriticalSection::get* presumably expects callers to hold a collection IS lock.

I do not understand how ShardingMigrationCriticalSection::get* and ShardingMigrationCriticalSection::exit* are concurrency safe, setting and accessing the same private class variable without a mutex to serialize such operations?

(note: this is going to remain on the execution backlog until the project design is finalized, then it will be passed to sharding to complete. this is to keep track of the work specifics)


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