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/conn/conn_layered.c:1322: LOCK_EVASION 202218 The thread 1 uses the value read from field "lock_flags" in the condition "(shared_metadata_session->lock_flags & 0x100U) != 0U". It sees that the condition is false. Control is switched to the thread 2.
/src/conn/conn_layered.c:1322: LOCK_EVASION 202218 The thread 2 uses the value read from field "lock_flags" in the condition "(shared_metadata_session->lock_flags & 0x100U) != 0U". It sees that the condition is false.
/src/conn/conn_layered.c:1322: LOCK_EVASION 202218 The thread 2 sets "lock_flags" 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 the thread 2 leaves the critical section, control is switched back to the thread 1.
/src/conn/conn_layered.c:1322: LOCK_EVASION 202218 The thread 1 acquires lock "__wt_spinlock.lock".
/src/conn/conn_layered.c:1322: LOCK_EVASION 202218 The thread 1 sets "lock_flags" to a new value. Now the two threads have an inconsistent view of "lock_flags" and updates to fields correlated with "lock_flags" may be lost.