Hi all,
Attached, another tricky piece of code. We actually try to exhibit a priority inversion by using the semaphore (which does not implement the priority inheritance protocol). We have the three following tasks: - meteoDataAcquisition: acquiring the mutex, spinning 10ms, releasing the mutex / priority 1 / delayed at 18ms, and then activated with a frequency of 1000 ms from its first activation (so normally, more or less activated at 1018, 2018, 3018, etc.) - busManagement: acquiring the mutex, spinning 5 ms, releasing the mutex / priority 10 / period of 20 ms. - comHandling: just spinning 10ms, period of 20 ms. So, the worst case would be when the meteoDataAcquisition acquired the mutex right before the busManagement, so we can say that the highest priority task will be delayed of 10ms at the worst; we put an alarm of 30ms, then no alarm will raise up; and indeed, it works like that. Doing the same stuff with the semaphore - just change WITH_MUTEX to 0 - should theoretically lead to an alarm since the comHandling will take the hand, delaying the busManagement over 30ms. Here comes the problem: if we leave the alarm at 30ms, the alarm raises up, as expected. But, if we change the alarm to 31ms, there is no alarm anymore... and we do not understand why? Normally we should see some alarms for some values from 31 to 35ms, since comHandling spins during 10ms. Mytery... Normally, the task meteoDataAcquisition is aperiodic, and activated on the basis of an IRQ. In order to simulate that, we put the task with a delay of 18ms (yes, that's the reason of 18 ;-)), activated each second (therefore causing the priority inversion systematically). But nothing happens! the system runs, but no alarm raises up with Many many thanks for your great help! Daniel
mytry.c
Description: mytry.c
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
