Hi Michael! On Wed, Feb 24, 2016 at 10:20:12AM -0800, Michael Andersen wrote: > > 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:) > > > It was my code that initially discovered it. I was quite deliberate about > not accessing the same object from two threads. In fact the timer that was > found to be in the list twice was one created by riot to wait for message > with timeout. Not ruling out user error, but it would have to be a more > subtle user error :-)
Do I understand this correctly: your application was not using multiple
threads accessing the same timer (i.e. xtimer_t struct), but you had still
concurrency problems with the timer? Can you elaborate on this?
> I've been busy on other things, so I have not had time to dig into where
> this is coming from, but a temporary hotfix that stopped my mesh from
> crashing was to put a modified version of remove_timer inside the critical
> section of add timer. At least that way the critical section does not
> contain the spin wait. Not advocating this as the solution, it's just a
> hack until I get time to improve it.
Would you be willing to share this hack with us? Maybe it gives us more
insights.
Cheers,
Oleg
--
panic("This never returns");
linux-2.6.6/kernel/power/swsusp.c
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list [email protected] https://lists.riot-os.org/mailman/listinfo/devel
