Originally reported as DevCom-10913616 / VSO-2495823.

My cleaned-up repro:

C:\Temp>type meow.cpp

#include <chrono>
#include <print>
#include <semaphore>
#include <stop_token>
#include <thread>
using namespace std;
using namespace std::chrono;

void f(stop_token stop) {
    binary_semaphore new_timer{0};
    for (int i = 0; i < 50 && !stop.stop_requested(); ++i) {
        const auto s = steady_clock::now();
        (void) new_timer.try_acquire_for(800us);
        const auto e = steady_clock::now();
        println("{}", duration_cast<nanoseconds>(e - s));
    }
}
int main() {
    jthread t(f);
    this_thread::sleep_for(1s);
}

C:\Temp>cl /EHsc /nologo /W4 /std:c++latest /MT /O2 meow.cpp
meow.cpp

C:\Temp>meow
200ns
100ns
0ns
0ns
0ns
0ns
100ns
0ns
[...]

I haven't fully analyzed this, but I observe that we still have some calls to GetTickCount64(), which IIRC uses the system clock instead of a steady clock:

🛠️ Previous fixes for this category of bugs

The other uses of GetTickCount64() in sharedmutex.cpp appear to be properly "checked" in the headers against steady_clock or the user's clock. This is after the series of fixes:

• VS 2022 17.9: Make this_thread::sleep_until clock-aware #3914
  • Fixed this_thread::sleep_until() to consistently use the given time_point's clock type, instead of also depending on the system clock. This also fixed this_thread::sleep_for() to consistently use steady_clock.
• VS 2022 17.11: Wait on condition variables independently on system time #4457
  • Fixed condition_variable::wait_until() and condition_variable_any::wait_until() to consistently use the given time_point's clock type, instead of also depending on the system clock. This also fixed condition_variable::wait_for() to consistently use steady_clock.
• VS 2022 17.12: Wait condition_variable_any for steady_clock #4755`
  • Fixed condition_variable_any::wait_for() to consistently use steady_clock.