[riot-devel] Odd problems with xtimer

Oleg Hahm oliver.hahm at inria.fr
Wed Feb 24 19:52:48 CET 2016

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

panic("This never returns");
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20160224/2d3e6d4c/attachment.sig>

More information about the devel mailing list