A data race happens when multiple exchange cursors are trying to access the OperationMemoryUsageTracker at once, e.g. 
https://github.com/10gen/mongo/blob/d23729c6faa6e3ecb0a9e5842be25477875019cf/src/mongo/db/query/client_cursor/clientcursor.cpp#L247-L248 

The memory tracker should not be shared between different exchange-producer cursors as the current paradigm is that there is only one memory tracker per client cursor.

One fix is that we should have multiple OperationMemoryUsageTrackers and merge the totals to the top level OperationMemoryUsageTracker once the exchange pipelines are done running. We would have one OperationMemoryUsageTracker per exchange pipeline.

These alternative fixes were also discussed but were less ideal:
1)  Make the OperationMemoryUsageTracker thread-safe by locking the memory tracker. This however would reduce the parallelism of exchange pipelines
2)  Not track memory for exchange cursors (may be problematic because we may want to track memory for these types of queries) by setting the incompatibleForMemoryTracking flag when building the expression contexts for the exchange pipelines here: https://github.com/10gen/mongo/blob/43a15f302b6b0f9848097bb580c18f6dc30a8427/src/mongo/db/commands/query_cmd/run_aggregate.cpp#L599-L611