summaryrefslogtreecommitdiff
path: root/tests/lib/libpthread/t_condwait.c
AgeCommit message (Collapse)Author
2022-12-11This test makes (made) a false assumption about the way thatkre
process scheduling works. That a process (or in this case, a thread) is no longer blocked at time T does not mean that it will resume execution at time T. The OS is free to devote resources to other processes/threads instead - all we should normally be able to expect is that if it is not unblocked before time T, that it will not start running before then. In general though, the pthread_cond_*wait() functions don't guarantee even that - but for this test, the possibility of something else randomly signalling the condvar isn't believable, so don't worry about that possibility (but do fail without calling strerror(0) on the off chance it does happen). Once we cease testing that the process resumed running before some particular time, we can stop dealing with qemu timekeeping issues, it might (seem to) take qemu twice as long as was requested before the thread resumes, but that's OK - the same thing could happen on a loaded system for other reasons. Beyond that, the test also has (had) a race condition. When using CLOCK_REALTIME though that clock needed to have advanced to T before the ETIMEDOUT should happen, there is no guarantee that it will stay >T (CLOCK_REALTIME is allowed to be reset backwards). So, only test that the current time (after ETIMEDOUT) >= T when we're using CLOCK_MONOTONIC - for CLOCK_REALTIME the time might have stepped back between when the ETIMEDOUT happened and when the thread obtains the current clock reading. For that case, all we can test is that the ETIMEDOUT actually happens. With much of what was there now gone, the code can be simplified, we no longer need to do timespec arithmetic, just one comparison (simpler to test that Tend >= Tstart+period than Tend-Tstart > period as we need Tstart+period for the abstime value for the timeout anyway). Note that this still tests for the issue reported in PR lib/47703 which is where the test came from in the first place. ps: we seem to be missing pthread_cond_clockwait() which is the same as pthread_cond_timedwait() except that the clock to use is passed as a parameter, rather than as an attribute of the condition variable.
2022-04-16fix various typos in comments and log messages.andvar
2019-08-11Re-enable the QEMU specific timing limits, but only an increased uppermartin
limit for now - let's see if that works on the test-bed.
2019-08-10PR lib/54440: adapt the FreeBSD change to this test and calculate timemartin
differences more exact, allowing between 0 and 1 s delay between the expected wakeup and the actual event happening. Also convert the QEMU special case code to the same scheme, but for now disable it (with XXX mark) and see if the proper timing limits fix that case too. If not, we will re-enable the QEMU special case.
2019-07-09return return atf_no_error() instead of 0 for consistency.maya
suggested by moritzbuhl in https://github.com/NetBSD/src/pull/11/
2017-01-16PR/51884: Ngie Cooper: Include and message fixeschristos
2013-04-12loosen the test only for qemu.christos
2013-04-12Make cond_wait_mono and cond_wait_real tests accept a wait time in thegson
range of 90% to 250% of nominal, to allow the test to pass under qemu which has a known issue where timing can be off by a factor of two.
2013-03-29fix printf formatschristos
2013-03-28Add pthread_cond_timedwait(3) test from PR/47703christos