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 error) - 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) - ? Opinions? Kaspar _______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
