[riot-devel] Odd problems with xtimer

Kaspar Schleiser kaspar at schleiser.de
Fri Feb 19 22:24:50 CET 2016

Hey Michael,

On 02/10/2016 11:08 PM, Michael Andersen wrote:
> One question, in the network stacks, are there ever two threads possibly
> using the same timer object? I ask because the timer_remove and the
> insert are in two different critical sections, and if there are
> concurrent calls with the same timer object then it might be possible to
> interrupt between the critical sections and insert a timer that is
> already in the list. What would then happen is that this loop
> <https://github.com/RIOT-OS/RIOT/blob/master/sys/xtimer/xtimer_core.c#L209-L211> would
> end with list_head equal to the timer (assuming no other timer has the
> same time), and then the next two lines would basically link the timer
> to itself.
> I could be wrong though, that is just a guess.

I think your analysis is correct, I managed to create a test case that
shows pretty much the behaviour you're describing.

Guarding most of xtimer_set() (using disableIRQ/restoreIRQ) fixes the
problem, but disables interrupts for the backoff spin loop.

While hanging within xtimer is probably the worst, I'm not sure what
would be the best semantic for concurrently setting the same timer object:

- return an error (cleanest, but currently xtimer_set() never returns an
- first xtimer_set() wins (easy to implement by somehow tagging the
timer object, but probably unexpected)
- second xtimer_set() wins (very hard to do as xtimer_set() can be
called in ISR context, and there's no way to wait for, e.g., a mutex)
- guard the whole timer setting procedure (would disable interrupts
while spinning)
- ?



More information about the devel mailing list