In an attempt to upgrade our toolchain (to i.e. GCC 9.3.0) I run into issues with timing of threads. Something that used to work fine with GCC 7.2.0 no longer works as fast as it did when I try to put my thread to sleep for a short amount of time (< 15 msec)
According to this: https://stackoverflow.com/questions/58436872/stdthis-threadsleep-for-sleeps-for-too-long that seems to match the default timer precision, but I would like to understand what changed in that regard. MINGW32_NT-10.0 HOSTNAME 2.9.0(0.318/5/3) 2017-09-13 23:16 x86_64 Msys g++.exe (Rev1, Built by MSYS2 project) 7.2.0 vs MINGW32_NT-10.0-17134 HOSTNAME 3.0.7-338.x86_64 2019-07-11 10:58 UTC x86_64 Msys g++.exe (Rev1, Built by MSYS2 project) 9.3.0 I'm a bit confused on how to achieve 100Hz timing on Windows using mingw32, preferably with a standard/cross-platform solution. (i.e. sleep_until) The goal is to make a worker-thread execute work with a fixed interval. Here's an MVP that demonstrates my "problem": #include <thread> #include <chrono> #include <iostream> #include <windows.h> int main() { auto start = std::chrono::high_resolution_clock::now(); for(int i = 0; i < 100; i++) { //Sleep(2); std::this_thread::sleep_until(std::chrono::high_resolution_clock::now() + std::chrono::duration<int, std::milli>(2)); } auto end = std::chrono::high_resolution_clock::now(); std::chrono::duration<double, std::milli> elapsed = end-start; std::cout << "Waited " << elapsed.count() / 100 << " ms\n"; std::cout << "Waited " << elapsed.count() << " ms\n"; } sleep_until averages around 16msec. Sleep(2) works better and comes a lot closer to 2 msec. Our real application uses 'pthread_cond_timedwait' to sleep until, but that shows the same issue. (= Frequency limit at +- 65 Hz) I've tried timeBeginPeriod(1) and timeEndPeriod(1), but that didn't help. I'm running this tool to check the current timer resolution: https://vvvv.org/contribution/windows-system-timer-tool Running the MVP does increase precision of the timer, but the results don't change. I've been searching the web for answers but I'm a bit lost. What can explain the difference in behaviour of the two msys2 environments on my system? Is it a regression in Windows 10 1803, as discussed in this PR with a workaround to force the timing to a lower resolution? https://github.com/RPCS3/rpcs3/pull/4579 Please advise. Anything that could point me in the right direction would be highly appreciated. Kind regards, Erik Disclaimer: This mail transmission and any attached files are confidential and are intended for the addressee only. If you are not the person or organization to whom it is addressed, you must not copy, disclose, distribute or take any action in reliance upon it. If you have received this message in error, please contact the sender by email and delete all copies of this message and all copies of any attached files. _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
