AuxTask... classes do basically the same: they create a thread which blocks reading from a pipe. Other threads can then send to that pipe a typed message. After a message is sent, the thread will wake up as soon as possible (depending on priority) and process the incoming data. As a particular case, you can use the version were no message is passed, which will result simply in the thread being scheduled without data to process, useful in some circumstances.
The difference between
AuxTaskNonRT is in the type of inter-thread communication.
AuxTaskRT uses a Xenomai message queue (basically the Xenomai-friendly version of pthread's
mq_*). This allows the created thread (which is a Xenomai thread) to receive messages and being scheduled without ever leaving primary (Xenomai) mode. This is more efficient if the thread is performing some RT-critical task and would not leave primary mode. For instance, a high-priority DSP co-routine could use this.
AuxTaskNonRT uses a Xenomai pipe (as seen in the
Pipe library), which keeps the created thread in secondary (Linux mode). This is more efficient if the thread is performing non-RT tasks which use Linux services (e.g.: disk, USB, network), as it would have to switch to secondary (Linux) mode to use those anyhow.
Mode switches (from primary to secondary or viceversa) are CPU intensive (you waste some 20-40us for each) and are best avoided especially if repeated thousands of times per second. Therefore, the choice of
AuxTaskNonRT depends on what type of activities are performed by your thread. Ultimately, if your task only runs occasionally, the performance would be mostly identical in both cases.
These two classes are not well engineered, which is why we tend not to publicize them much. Some issues:
- they should be templated or subclassed instead of having three different constructors, three different
create() methods and three different
schedule() methods just to allow for three different types of messages to be passed.
- there is probably plenty of duplicated code around
- they both create a Xenomai thread, whereas only the
RT one should strictly do that
- they don't allow to set the length of the pipe/message queue
AuxTaskNonRT should probably use the
Pipe library instead of reimplementing it
- the depend on
BELA_AUDIO_PRIORITY without a good reason