Status() doesn't need a lock

[oldnewthing]

Reading the status of an IAsyncXxx does not require a lock because the operation is already inherently racy. Change the m_status to a std::atomic so we can access it from multiple threads without a lock. Everybody who accesses it under a lock can use std::memory_order_relaxed because the lock is providing the memory ordering protection. The Status() method uses acquire order to handle the case where one thread publishes the IAsyncXxx with release semantics, and another thread picks it up and interrogates the status. Causality requires us to report the status that was published by the first thread, so we need acquire.

Reading the value while another thread is changing it is okay, as long as we get either the entire old value or the entire new value, which is what std::atomic guarantees. If we read a stale value, that's okay, because multithreading means that we could have executed a few cycles sooner, in which case the stale value was current at the time.

If anybody makes a decision based on the status, they will have to return to the IAsyncXxx to get the Result or the ErrorCode, and those will take the lock and ensure consistency of the other protected members.

This change remove a lock from the await_transform method, which would otherwise need to be entered (and exited) at every co_await operation. The code sequence

    lea      rcx, this->m_mutex
    call     AcquireSRWLockExclusive
    mov      rdi, this->m_status
    lea      rcx, this->m_mutex
    call     ReleaseSRWLockExclusive
    cmp      rdi, 2
    jz       throw_cancelled

becomes

    cmp      this->m_status, 2
    jz       throw_cancelled

which avoids two calls, frees up a nonvolatile register, and avoid a spill of volatile registers.

Relaxed order access to atomics is implemented as a simple load or store on all supported platforms, so the change from a simple variable to a std::atomic has no code generation effect for all of the other uses.