[riot-devel] Odd problems with xtimer

malo malo at 25cmsquare.io
Wed Feb 24 14:56:32 CET 2016


Hello Kaspar,
sorry for "out out order" message, but I was not in the list when this
thread was started.

Adding my two cents:
the current xtimer is "just" not thread safe and should not be
used/set from multiple threads (hope we agree on this). the question
is, if there is somewhere in the riot core single xtimer_t* set from
multiple threads?
Or was just userspace misuse...
Hope the second is the case:)


As for returning error on xtimer_set - what you would do with the return value?
maybe something like?:
while (true)
{
  if (!xtimer_set())
  {
    yield();
  }
  else
  {
    break;
  }
}
quite ugly...


Sure there should be check in _add_timer_to_long_list and
_add_timer_to_list for duplicates and assert in the case that trying
to add pointer which is already in - just to warn user that is doing
something bad.

wbr
malo

> <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20160224/02d55a33/attachment.html>


More information about the devel mailing list