Please disregard

Description of Linked Ticket

Summary

Clarify thread-safety semantics of and reduce concurrent accesses to core data types, in particular OperationContext and Client.

Motivation

Members of Client and OperationContext may be accessed from threads not owning the Client, so long as:

• The Client lock is acquired.
• The access is a read, and not a write.
• The thread owning the Client always acquires the Client lock before writing to the member.

The first motivation for this project is to better document and enforce these requirements (e.g., using invariants to prevent unsafe multi-threaded accesses). Next, we should evaluate the possibility of reducing the frequency of acquiring the Client lock. This is mainly due to using spin-locks to implement the Client lock and to avoid unpredictable performance implications of waiting on a spin-lock acquired by a non-running thread. For example, is it possible/desirable to improve how currentOp is populated and make it work with less impact on the Client thread by not acquiring the Client lock?

Finally, we should reevaluate the efficiency of using individual, non-partitioned atomics (and strong memory ordering) to maintain stats shared between multiple threads, in particular threads processing ingress commands.

Documentation

Product Description
Scope Document
Technical Design Document
Docs Update