> > Actually that is what I thought in the first place, however Jan's > > comment "That's not true, Xenomai threads can run in non-RT scheduling > > classes as well. They may just gain RT priority while holding some > > lock that is requested by a RT thread as well." made me think I was > > wrong... > > > > So we would really need a SCHED_IDLE for Xenomai then to solve this problem? > > I don't think so. But we do need to solve the issue that a non-RT thread > stays too long in primary mode and is thus scheduled by Xenomai with the > wrong priority /wrt other Linux task at its level. > > For the time being, you can work around this by issuing a Linux syscall > before entering long processing loops - unless your task doesn't do this > anyway, e.g. to perform some Linux I/O. >
I think that's need. Currently the statistics task takes a mutex and waits on a message queue for messages. That's the only time it should potentially run in primary mode. After it returns the Mutex it should continue running with a policy similar to SCHED_IDLE to give other tasks a chance to run. I see how switching back to secondary mode could be achieved by issuing a Linux syscall. Is there another way which doesn't involve changing the source code of our application? (The proper way?) Andreas _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
