> -----Message d'origine----- > De : Philippe Gerum [mailto:[EMAIL PROTECTED] > Envoyé : jeudi, 20. juillet 2006 14:04 > À : ROSSIER Daniel > Cc : [EMAIL PROTECTED]; [email protected] > Objet : RE: [Xenomai-help] Strange behaviour w/mutex&semaphore > > On Thu, 2006-07-20 at 13:17 +0200, ROSSIER Daniel wrote: > > > > > -----Message d'origine----- > > > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > Envoyé : jeudi, 20. juillet 2006 13:03 > > > À : ROSSIER Daniel > > > Cc : [email protected] > > > Objet : Re: [Xenomai-help] Strange behaviour w/mutex&semaphore > > > > > > ROSSIER Daniel wrote: > > > > Hi all, > > > > > > > > I've a strange behaviour with the attached piece of code. > > > > It's really simple: there are 3 tasks and we're spinning within the > task > > > in order > > > > to simulate task load. > > > > > > > > It's a pure academic exercice, so don't try to think about the > > > usefulness of this code ;-) > > > > > > > > > > > > Actually, after insmod'ing the code into the kernel, the system > freezes > > > and > > > > the "meteoDataAcquisition" task is suspended runaway by the internal > > > xenomai watchdog. > > > > > > > > Why? > > > > > > > > Anything wrong in this code? > > > > > > Check the values you assign to rt_task_set_periodic. Kind of... fast? > > > > No, with at these frequencies, there is no problem (the jiffy is at > 1ms). Actually, putting TM_NOW in the rt_task_set_periodic() instead of 18 > as it is, we noticed that it works. > > Removing the mutex & semaphore stuff, with the delay in set_periodic(), > does not change the behaviour. > > We came up with this issue after another one, actually, with a more > sophisticated code showing a priority inversion. We reduce the code, and > then find this issue. I do not know it both issues are related, but I'd > like > > to solve this one first. > > > > - rt_task_set_periodic(&meteoDataAcquisitionTask, 18, 1000); > + rt_task_set_periodic(&meteoDataAcquisitionTask, rt_timer_read() + 18, > 1000); > > The current call should return with -ETIMEDOUT, in which case, the > associated acquisition thread would enter a runaway loop, with > rt_task_wait_period() systematically bailing out upon the same error, > which in turn makes the task sucking all the available CPU. Then came > the relentless watchdog...
Of course! It's absolute time as well explained in the API. Thanks a lot Philippe; I need some Holidays ;-) So, I will now post the real issue we have with the priority inversion, probably another easy fix to find out ;) > > > > > > > > > > > > Thanks for any advice. > > > > > > > > Daniel > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > ---- > > > > > > > > _______________________________________________ > > > > Xenomai-help mailing list > > > > [email protected] > > > > https://mail.gna.org/listinfo/xenomai-help > > > > > > > > > > > _______________________________________________ > > Xenomai-help mailing list > > [email protected] > > https://mail.gna.org/listinfo/xenomai-help > -- > Philippe. > Daniel _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
