Skip to content

xtimer: Fix backoff condition in _xtimer_set_absolute #7628

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jnohlgard wants to merge 1 commit into from
Closed

xtimer: Fix backoff condition in _xtimer_set_absolute #7628

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion sys/xtimer/xtimer_core.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -176,7 +176,9 @@ int _xtimer_set_absolute(xtimer_t *timer, uint32_t target)
DEBUG("timer_set_absolute(): now=%" PRIu32 " target=%" PRIu32 "\n", now, target);

timer->next = NULL;
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);

@smlng smlng Sep 23, 2017

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@jnohlgard jnohlgard Sep 24, 2017

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

_shoot(timer);
Expand Down