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/watchdog/watchdog.cpp:404: LOCK_EVASION 145951 Assigning: "started" = "this->_state == mongo::WatchdogMonitor::State::kStarted".
/src/mongo/watchdog/watchdog.cpp:404: LOCK_EVASION 145951 Thread1 reads the field "_state".
/src/mongo/watchdog/watchdog.cpp:408: LOCK_EVASION 145951 Thread1 uses the value read from field "_state" in the condition "!started". It sees that the condition is false. After Thread1 leaves the critical section, control is switched to Thread2.
/src/mongo/watchdog/watchdog.cpp:402: LOCK_EVASION 145951 Thread2 acquires lock "mongo::WatchdogMonitor._mutex".
/src/mongo/watchdog/watchdog.cpp:404: LOCK_EVASION 145951 Thread2 reads the field "_state".
/src/mongo/watchdog/watchdog.cpp:408: LOCK_EVASION 145951 Thread2 uses the value read from field "_state" in the condition "!started". It sees that the condition is false.
/src/mongo/watchdog/watchdog.cpp:420: LOCK_EVASION 145951 Thread2 sets "_state" to a new value. Note that this write can be reordered at runtime to occur before instructions that do not access this field, even into (but not to the other side of) preceding locked regions. Control is switched back to Thread1.
/src/mongo/watchdog/watchdog.cpp:420: LOCK_EVASION 145951 Thread1 sets "_state" to a new value. Now the two threads have an inconsistent view of "_state" and updates to fields correlated with "_state" may be lost.