Problem

On a 100% findById workload, _extractReadConcern is called on every query via the primary dispatch path: ServiceEntryPointShardRole::handleRequest → ExecCommandDatabase::_extractReadConcern → ReadWriteConcernDefaults::getDefault → ReadThroughCache::acquire → pthread_mutex_lock. In the common case — no cluster-wide read concern (CWRC) configured, no explicit read concern on the request, no transaction, external client — the function performs substantial work (including a cache acquire and mutex) only to return an implicitDefault ReadConcernArgs. Profiling shows ReadWriteConcernDefaults::getDefault consuming ~69% of _extractReadConcern's cumulative time, making it a measurable overhead on every query.

Solution

A cheap AtomicWord<bool> _customDefaultReadConcernSet field is added to ReadWriteConcernDefaults and kept up-to-date by setDefault(). A fast-path early return is inserted at the top of _extractReadConcern that checks six inexpensive conditions (no transaction start, no client-supplied read concern, no in-flight multi-document transaction, not an internal client, not a direct client, no custom CWRC via isCWRCSetFast()). When all six hold, the function short-circuits and returns implicitDefault without touching the cache or acquiring any lock. The isCWRCSetFast() method uses loadRelaxed() — a single instruction on ARM64 — and is conservative: it may briefly return true after a CWRC is cleared, but never returns false when a CWRC is actually set.