[riot-notifications] [RIOT-OS/RIOT] tests/xtimer_usleep: recognize negative offset (#11493)

Gaëtan Harter notifications at github.com
Tue May 7 17:03:30 CEST 2019


Returning before, whatever the amount is, is not what I would expect as a user and it is not what the API says.

If my resolution is 30us, I know I cannot get better precision than a few multiple of 30us. Also I should take into account all the delays to know what I should have in the worst case and I must deal with the worst case as it can happen. If my precision is lower that what I need, I am screwed.


The usage currently assumes there is a way to have a timer after an expired time.
The `sema` module does this which used by `posix_semaphore`.

`tests/posix_semaphore` on `frdm-kw41z`.
```
2019-05-07 16:20:51,089 - INFO # ######################### TEST4:
2019-05-07 16:20:51,090 - INFO # first: sem_init s1
2019-05-07 16:20:51,094 - INFO # first: wait 1 sec for s1
2019-05-07 16:20:52,093 - INFO # first: timed out
2019-05-07 16:20:52,098 - INFO # first: waited only 999970 usec => FAILED
2019-05-07 16:20:52,099 - INFO # ######################### DONE
```
And here it also happened after 30us
```
2019-05-07 16:37:30,761 - INFO # ######################### TEST4:
2019-05-07 16:37:30,761 - INFO # first: sem_init s1
2019-05-07 16:37:30,765 - INFO # first: wait 1 sec for s1
2019-05-07 16:37:31,764 - INFO # first: timed out
2019-05-07 16:37:31,769 - INFO # first: waited 1000031 usec
2019-05-07 16:37:31,770 - INFO # ######################### DONE
```

So here code using `xtimer` must assume tick difference in the future and the past, not only for sleep but also for `xtimer_set` so the callback done in interrupt context.

And for the precision, you can only assume the guarantee that can happen in the worst case. If one high priority thread can do small sleeps, a lower priority thread should already assume it can be descheduled for `XTIMER_BACKOFF` ticks at any time as the other thread could have `xtimer_usleep` spin up to `XTIMER_BACKOFF` ticks.
And if this happens just before calling the `xtimer_usleep/xtimer_set` function, it would be at least 5 ticks after what is expected as it is a relative time.

With timing, I would only consider the worst case.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/RIOT-OS/RIOT/pull/11493#issuecomment-490118751
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190507/299c0a8a/attachment.html>


More information about the notifications mailing list