Using SCHED_FIFO for TT Nets

[moiri]

In order to improve the predictability of time-triggered nets I plan to use the SCHED_FIFO policy as follows:

• every temporal firewall uses SCHED_FIFO with priority prio_tf
• every single net that is surrounded by a temporal firewall on each side uses SCHED_FIFO with priority prio_net_1
• every single net in a composed net N where N is surrounded by by a temporal firewall uses SCHED_FIFO with priority prio_net_n
• all other nets use SCHED_OTHER

~Not to worry about priority inversion as temporal firewalls only block on a timer but not on read and write operations. Further, nets that are "guarded" by temporal firewalls run with the same priority~.

Observation: priority inversion is also possible in Streamix, as also FIFO resources are protected with mutexes (which can be locked by threads with lower priority)

Observation: zlog and Priority inversion: If a log file is locked by an event-triggered net et and et is then preempted by a temporal firewall tf which in turn is pre-empted by a time-triggered net tt we have a problem of priority inversion (until tt reaches a log instruction).

Note: Priority inversion requires three priority levels. A mutex is able to cope with only two levels.

How to avoid priority inversion:

1. if prio_tf > prio_net_1 > prio_net_n
   • the fifo mutex must be configured with priority inheritance
   • each zlog call must be protected with a mutex which is configured with priority inheritance
2. if prio_tf = prio_net_1 = prio_net_n no priority inversion can occur

[moiri]

zlog uses pthread_rwlock to handle multi-threaded applications. It looks like priority inversion is indeed a problem here.

I can think of three ways to solve this problem:

1. use a mutex (which was initialized with the priority inheritance protocol) to protect calls to zlog functions
2. use seperate log files for each priority level
3. use Streamix for logging
4. use only one RT priority level

The first and the third option might have a serious impact on performance (has to be tested) and the second option calls for disaster because the output log files can be defined in the config file. The fourth option might be sufficient following the arguments:

• if a system cannot cope with TT nets that are set to the same priority, it will also not be able to cope with TT nets of different priorities.
• A temporal firewall is not more important than the framed net: the functionality cannot be delivered if either of them miss a deadline.

[moiri]

Note that in order to grant a user the permission to run RT threads at a given priority the file /etc/security/limits.conf needs to be adapted. The following line must be added:

<domain>   -    rtprio     99

where <domain> can be:

• a user name
• a group name, with @group syntax
• the wildcard *, for default entry

[moiri]

In a non-rt Linux kernel, kernel threads are not pre-empted by threads of higher priority.

Several options exist to enable kernel thread pre-emption. This Article talks about this topic.

This Post describes how to install a RT patch in Ubuntu.

[moiri]

Currently, logs are protected with a mutex to prevent priority inversion. Unfortunately, this lock is done before the log level check. This means that even if only errors are activated, the system will still lock on each debug message even if debug is disabled.

Right now I cannot see a solution for this problem. Maybe just ignore the priority inversion problem because it is very unlikely to happen?