On Fri, 2006-07-21 at 15:03 +0200, Jan Kiszka wrote: > Daniel Simon wrote: > > On Fri, 21 Jul 2006 14:12:47 +0200 > > "ROSSIER Daniel" <[EMAIL PROTECTED]> wrote: > > > >> but it might be at the spin() level. > > > > I have observed that the behaviour of rt_timer_spin() does not fit with > > the expected behaviour as described in the doxygened comment: its actual > > awakening time do not increase when it is preempted. > > > > According to the code in timer.c (using 2.1.2) the wakening time seems > > to be computed once for all at the beginning of the function call. > > > > Am I right? > > Partially. The doc doesn't claim that the time during preemption will > get added to your requested spin time. Depending on how long you got > preempted, the delay /may/ be longer (until the preemption actually > ends). Anyway, this could explain some misunderstandings in this tricky > scenario here. > > [There is actually one undocumented issue of rt_timer_spin: if the task > is migrated to another CPU during spin, the end time will not match the > new timebase. So, one should not forget to pin such spinning tasks to > one CPU first when running on SMP.] >
Fortunately, this scenario cannot happen, since migration is always a self-targeted action, i.e. tasks can only request migration for themselves, Xenomai never ever forcibly migrates RT threads on its own decision. So if the task spins, it can't request any migration. If the migration comes first, then the spinning occurs on the target CPU, so this is still a non-issue. > Jan > > _______________________________________________ > Xenomai-help mailing list > [email protected] > https://mail.gna.org/listinfo/xenomai-help -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
