TimerComponent creates threads internally that do not respect CPU_AFFINITY

[jlack1987]

We regularly use the TimerComponent for ticking some of our RT threads which we also pin to CPU cores. When inspecting the running processes using htop we noticed there were a number of RT scheduled threads that were not respecting our CPU_AFFINITY that we set for the timers and other components. After looking into the code I have found this line where an os::Timer thread is created which is not required to respect the CPU_AFFINITY of the TimerComponent.

cc @dustingooding

[meyerj]

Indeed, the current implementation of the TimerComponent does basically nothing in its own thread (which would be affected by assigning a CPU affinity, and runs a high-priority RTT::os::Timer as a background process. This thread does nothing but writing to the timer ports, which should be fine, given that the timer ports are connected using lock-free connections and you don't use exotic activities like SequentialActivity. The actual work triggered by the timers is executed in the thread of the other components and respect their CPU affinity.

Apparently that behavior is not what you would expect. I don't see a big problem in running Timer::loop() from the updateHook() of the TimerComponent instead of a separate thread, either directly or via a SlaveActivity. That would probably solve the issue, but the priority assigned to the TimerComponent needs to be equal to or higher than the highest-priority component it is supposed to trigger. We could set the scheduler and priority of the TimerComponent's thread to SCHED_FIFO and RTT::os::HighestPriority in its constructor by default.