xtimer: Fix backoff condition in _xtimer_set_absolute #7628
Conversation
When the target is inside the next long_period, the previous condition was incorrect. The new condition should give the same result regardless of whether there is a long_period tick coming soon or not.
jnohlgard
added
Type: bug
| if ((target >= now) && ((target - XTIMER_BACKOFF) < now)) { | ||
| /* The (target - now) difference works across the long tick rollover, there | ||
| * is no need to check for (target > now) first. */ | ||
| if ((target - now) < XTIMER_BACKOFF) { | ||
| /* backoff */ | ||
| xtimer_spin_until(target + XTIMER_BACKOFF); |
There was a problem hiding this comment.
Side question, which bothered me for some time: why add XTIMER_BACKOFF here (again?). Assuming XTIMER_BACKOFF is 50us (default for many boards), and I use something like xtimer_usleep(40) the result is that my apps actually sleep 90us right? Though its more likely that the target time of 40us ahead has already (or nearly) passed by the time this call gets here, anyway, but still this seems wrong to do here, or not?
There was a problem hiding this comment.
The reason for adding a backoff here is that there is a non-zero amount of time that has passed between the _xtimer_now call and the xtimer_spin_until call, so there is a risk that target is already in the past, which will make the system spin for a full lltimer cycle instead of just returning. This is not an ideal solution though, but I don't have any better ideas at the moment.
|
This change removes a safeguard against setting timers in the past (the |
|
superseded by #9211, hence closing |
When the target is inside the next long_period, the previous condition
was incorrect. The new condition should give the same result regardless
of whether there is a long_period tick coming soon or not.