xtimer: periodic race

[Josar]

This PR solves a race condition.

If the workload is high like in test/xtimer_drift and the last_wakeup is not updated with the proper time the next target might be also allready past now, dependend on the periode choosen.

This PR sets the last_wakeup to now if the target is allready reached.

EDIT:
I change the implementation so the past targets are skipped and the period is fixed.
Means past targets get skipped, one execution with hight jitter, next execution in periode with minimal jitter.

Tries to handle the same problem as #7629 submitted on 20 Sep 2017.

[kaspar030]

Hm, now the period drifts on underflow, right? E.g., start is 0, period is 10, if one step at N*10 is missed by M, from that point on the timer wakes up at (N*10 + M), thus the period moved.

[Josar]

@kaspar030 thats correct.

If this happens this means there are to much higher prior task, or they take to long, and the period can not be fullfilled. It would be cancelled out if this is only one period with high load. then the next target will be on spot again.

But if it happpens every 10 period and If the period does not move the target will get closer to now.
At some point, If the higher prior task needs longer than the period, there will be mulltiple underflows. Now if the higher prior task, as in xtimer_drift, depends on the xtimer_periodic_wakeup() it will be triggered faster than expected as there is work to compensate. As the higher prior task will now again need multiple periods the target will always be smaller than know, race condition.

with this fix there will be a continues growing drift from the starting target, but the it will keep running.

[kaspar030]

I guess this is a matter of expected / desired behaviour.

1. if the wakeup function realizes it is late, is it OK to skip one or more "ticks", or should there be one wakeup for each missed tick, even if they'd happen right away?
2. if yes, trigger one ASAP or at the next planned "tick"?
3. if ASAP, from then on, shift the period or try to get back to the original period (set (last = now) or last = (expcted + period)?

What would we expect?

[Josar]

@kaspar030 this was the first fix.

But for sure skipping and setting the next target in regard to the old target is a possible solution which would not introduce a jitter but only a drift.

[Josar]

I change the implementation so the past targets are skipped and the period is fixed.

[Hyungsin]

@Josar, glad to find another person working on xtimer. I also opened a PR regarding xtimer implementation for eliminating race conditions in xtimer #9530.

[Josar]

@kaspar030 @cladmi @gebart What would be the desired behaviour in your opinion?
What do you think about this approach?

[Josar]

Is there any chance to work on this PR. As this handles a problem which is idling around quite long.
See the solution of @gebart from 2017 84f42e2

[Josar]

@gebart and @miri64 as you have worked on #7629, which tries to solve the same issue, could you have a look at this?

[Josar]

Ping Pong

[Josar]

@kYc0o @kaspar030 @cladmi @gebart seems there are still people having problems with this issue. Maybe someone could have time to look into this PR.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[miri64]

@MichelRottleuthner @JulianHolzwarth can you have a look if this PR is still valid after the xtimer rework?

[kaspar030]

I'm closing this as xtimer is deprecated. Feel free to reopen if you disagree.