Re: [Xenomai-help] General question on Native Skin tasks

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2309 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]