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/cursor/cur_backup.c:262: LOCK_EVASION 169519 The thread 1 uses the value read from field "owning_thread" in the condition "session->thread_check.owning_thread != __tmp_api_tid". It sees that the condition is true. Control is switched to the thread 2.
/src/cursor/cur_backup.c:262: LOCK_EVASION 169519 The thread 2 uses the value read from field "owning_thread" in the condition "session->thread_check.owning_thread != __tmp_api_tid". It sees that the condition is true.
/src/cursor/cur_backup.c:262: LOCK_EVASION 169519 The thread 2 sets "owning_thread" 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/cursor/cur_backup.c:262: LOCK_EVASION 169519 The thread 1 acquires lock "__wt_spinlock.lock".
/src/cursor/cur_backup.c:262: LOCK_EVASION 169519 The thread 1 sets "owning_thread" to a new value. Now the two threads have an inconsistent view of "owning_thread" and updates to fields correlated with "owning_thread" may be lost.