If you have two real-time threads that you need to communicate between, use the RtMsgFifo class instead. This is unidirectional, but you can use two for bidirectional use.
The question to me is whether these are really real-time threads - i.e.:
- are they performing functions whose result needs to be ready at a predictable time?
- Are they accessing only real-time resources?
If any of these answers is no, then you are unlikely to achieve much benefit from using RtMsgFifo or RtNonRtMsgFifo (aka Pipe), which are wrappers for Xenomai's communication primitives. You may be better off using classes from the standard library, especially if they are running at high frequency: when a thread switches between Xenomai and Linux mode and vice-versa there is a context switch, which means a handful of microseconds of wasted CPU time. If this happens hundreds of times per second, it may take a significant chunk of the overall CPU time. On the other hand, if it happens ten or fewer times per second, it's probably a non-issue.
If relevant to your application, you can also mix-and-match, e.g.: RtNonRtMsgFifo aka Pipe for "scheduling" a std::thread of any priority from a Xenomai thread running in primary mode. The scheduled thread then in turn pulls data from a std::queue populated by another thread. Btw, I wouldn't assume anything from the standard library to be thread-safe, so you should use locks when accessing the std::queue (or std::list or std::vector, whatever) from either side. Using locks (in combination with a synchronisation variable) also allows you to block a thread till work is available for it, e.g.: until the queue length is non-zero, similarly to what is achieved with RtNonRtMsgFifo. In RtLock.h there are RtMutex, RtConditionVariable and RtSync. RtSync is a wrapper around the other two for synchronisation purposes which can serve as an example on how to synchronise threads (even if you make these non-RT by removing the BELA_RT_WRAP() stuff).
