Check of thread-shared field evades lock acquisition

The data guarded by this critical section may be read while in an inconsistent state or modified by multiple racing threads. Checking the value of a thread-shared field outside of a locked region to determine if a locked operation involving that thread shared field has completed.
/src/mongo/db/operation_id.cpp:139: LOCK_EVASION 144695 Thread1 uses the value read from field "isInitialized" in the condition "state.isInitialized". It sees that the condition is true. Control is switched to Thread2.
/src/mongo/db/operation_id.cpp:139: LOCK_EVASION 144695 Thread2 uses the value read from field "isInitialized" in the condition "state.isInitialized". It sees that the condition is true.
/src/mongo/db/operation_id.cpp:145: LOCK_EVASION 144695 Thread2 sets "isInitialized" to a new value. Note that this write can be reordered at runtime to occur before instructions that do not access this field within this locked region. After Thread2 leaves the critical section, control is switched back to Thread1.
/src/mongo/db/operation_id.cpp:140: LOCK_EVASION 144695 Thread1 acquires lock "mongo::OperationIdManager._mutex".
/src/mongo/db/operation_id.cpp:145: LOCK_EVASION 144695 Thread1 sets "isInitialized" to a new value. Now the two threads have an inconsistent view of "isInitialized" and updates to fields correlated with "isInitialized" may be lost.