[SERVER-59157] Add support for a shared-mutex type Created: 06/Aug/21  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Internal Code
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Amirsaman Memaripour Assignee: Backlog - Service Architecture
Resolution: Unresolved Votes: 0
Labels: sa-remove-fv-backlog-22
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-59185 std::shared_mutex and boost::shared_m... Closed
Related
is related to SERVER-51055 ServiceContext getters/setters are ra... Open
is related to SERVER-57811 API to start storage with alternate l... Closed
Assigned Teams:
Service Arch
Participants:

 Description   

We are having new use-cases that could benefit from a shared-mutex type. Examples include but are not limited to:

  • SERVER-57811: uses a custom SpinLock implementation to swap the storage engine.
  • SERVER-51055: introduced SyncUnique to avoid data-races while setting/getting ServiceContext fields (e.g., fastClockSource).

The absence of a shared-mutex type leaves developers with no option other than introducing new, case-specific shared-mutex-like types.

The desired interface is very similar to std::shared_mutex, but the implementation should address the following:

  • The shared path must be very fast, and almost impose no cost.
  • Both exclusive and shared accesses must be interruptible (e.g., by accepting a object that implements the Interruptible interface).
  • Often, it is okay to delay the exclusive path in favor of the shared path. This should be considered in implementing the shared-mutex type.

The aim of this ticket is to:

  • Identify the shared-mutex implementation that fits the above considerations/requirements.
  • Wrap the implementation inside a Mongo library under stdx namespace.
  • File tickets to replace existing code that is no longer relevant with the introduction of the new shared-mutex type.

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