you'd need to use a lock or condition variable (that's how it's implemented in Bela's AuxiliaryTask API) in the std::thread, so that when it waits on it, but then you wouldn't be able to signal the lock or condition variable from the audio thread unless those are Xenomai locks/variables. The only inter-domain (Linux -> Xenomai or Xenomai -> Linux) way of communicating is the Pipe (aka RtNonRtMsgFifo). Everything else requires both threads to be Xenomai threads. See RtLock.h, RtThread.h, RtWrappers. To turn a std::thread into a Xenomai thread, you could call turnIntoRtThread() once from the std::thread, but then the resulting thread is no different from what you'd get starting it as a RtThread or AuxiliaryTask (which is an RtThread under the hood).
giuliomoro Yes that is good enough; even usleep(0); (or pthread_yield()) should work.
Actually I recently realised that while usleep(0) seems to work, it is not guaranteed by the standard that it should (or that it will continue to), so pthread_yield() is the right way of doing it .
Ward Do you mean that if I let a std::thread run heavy tasks instead of Bela AuxTasks I wouldn't need to put usleep(0) in all places I suspect of sometimes being slow. That Linux decides when to yield the task and resume?
By default a thread created from the main thread has SCHED_OTHER. Linux will assign each thread with SCHED_OTHER a quantum of time, then stop it and move on to the next one. As soon as you start assigning priorities you need to move from SCHED_OTHER to SCHED_FIFO or SCHED_RR. See here for more details here. Note that the above this is true of both Linux and Xenomai tasks. The only advantage of a Xenomai task is that it can call Xenomai functions (e.g.: the mutex/condition variables above) and it will not be preempted by the Linux kernel as long as it's running in primary (Xenomai) mode.
If you need to synchronise a std::thread elegantly (i.e.: so that it stops and waits for something), use a RtNonRtMsgFifo aka Pipe to write a dummy character from the audio thread with writeRt() while the thread waits on it with readNonRt(), then discard the char and go on. This is more or less what AuxTaskNonRt does. The issue here is that if the audio thread signals it more than once while the thread is running, it may start to fall behind and the pipe starts filling up. Workarounds are to send a message back to the audio thread to say you are done, or to always drain the pipe from the rt thread: while(1 == pipe.readNonRt(c));, though if the audio thread is writing to it way too fast, the secondary thread may spend too much time drying the pipe and not enough time doing the work.
