在 2023/10/31 08:06, Jacek Caban 写道:
I find the claim that it's fine to wait for longer to be questionable. GetTickCount's value may be off by up to 16 ms, so the way elapsed time is calculated in those helpers may be off by up to 32 ms. I guess that precise waits matter mostly for short timeouts in scenarios where timeouts are semi-expected to happen and then the overhead of over-waiting may be not negligible. I wonder if the observed too short waits are an effect of measurements problems in tests, but I can't judge on that without seeing tests. All operating systems will have some sort of accuracy considerations in this area and kernel is in a better position to handle it than we are.
There is a requirement, formally specified in `nanosleep()` [1] which takes a relative timeout, that a program may not wait shorter than requested. On the other hand `pthread_mutex_timedlock()` etc. take absolute timeouts but it seems they are not allowed to wake up prematurely [2], except `pthread_cond_timedwait()` which is subject to spurious wakeups.
Given that a program may not wait shorter, it can be concluded that all premature wakeups are either spurious or results of having been interrupted; otherwise the behavior of these functions will be unpredictable. For example, a timed wait function that ignores any request below 100 ms is less likely to be useful.
[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/nanosleep.html [2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_timedlock.html -- Best regards, LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
