Brian L. wrote: > Ok; What xenomai priority in the 1-99 scheme corresponds to the > priority of normal user-level posix threads?
Depends on the mode of your xenomai thread: when in primary mode (the hard-rt mode where the xeno threads live by default), those 99 levels are actually above all linux priorities. But when your thread enters secondary mode to issue some linux syscall or handle a normal signal, its priority gets mapped 1:1 on the linux range. This means, e.g., that a xenomai thread with prio 50 in secondary mode gets overruled by a normal linux thread with prio 60 but not by a xenomai thread in primary mode even with prio 1. > > The application I'm building has realtime and non-realtime components > which share some native-skin objects. I am constructing my > time-critical and non-time-critical threads using rt_task_create. I > would like almost all of them to behave exactly as ordinary > non-xenomai posix threads do with regard to priority and starvation. Why do you create the non-rt threads also via rt_task_create? This just introduces unneeded load on the RT subsystem. > > The example was contrived to support my question. In practice, I do > call mlockall. Also, my development machine has no swap space, so > mlockall probably shouldn't have an effect. I does, thanks to the lacy memory allocation scheme of glibc (alloc on access). > > What does this watchdog do and where is it documented? I'm surprised I > haven't heard it mentioned before, since it seems rather important. It's a kernel option (isn't it mentioned somewhere in the docs? then it needs fixing). The scheme is that after 4 seconds (if I remember the number correctly) of continuous xenomai activity with linux leaving no breath, the currently running xenomai thread gets suspended. This may be the wrong one when you are unlucky, but then one of the next round will hit the offender. We may think about improving this scheme a bit (suspending the lowest-prio thread?). I helps to return your system to "interactive mode", analysing what went wrong and maybe cleaning it up. > > So far, I've not intended to introduce any "real-time" features; What > I'm doing is very vanilla stuff that I'd normally do with pthreads. > > Brian > Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
