Andreas Glatz wrote: >>> 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?)
The proper way would be to not having to change the application code. But this workaround (Linux syscall or *_set_mode()) is required until we improve the nucleus. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
