shuhaowu
commented
3 months ago Hi! It seems like there are several concepts involved here:
POSIX signal handling in cactus-rt is designed to allow your application to listen to a POSIX signal. The primary intended usage for this is for the application to gracefully shutdown upon receiving of a termination signal from outside the process. The signal_handling_example shows how this can be done via either the wait on semaphore method or the busy wait method: https://github.com/cactusdynamics/cactus-rt/blob/0ee4132/examples/signal_handling_example/main.cc#L47-L55.
Waking a non-RT thread from a RT thread is not easily solvable by cactus-rt. It seems like this is what you want? There are in principle two solutions to this problem:
- Have your real-time thread set a condition to be true and have the non-realtime thread spin wait (either busily or with a sleep).
- This method works, but has the drawback of CPU usage, live locks, or latency.
- Use condition variables or semaphores to wake up other threads blocked on those condition variables or semaphores.
- This method doesn't work on Linux with existing glibc implementations because the
sem_*andpthread_cond_*are not real-time friendly due to the lack of priority inheritance support (for details see glibc bug 11588 and the 2020 talk of "librtpi: Conditional Variables for Real-Time Applications" by Gratian Crisan). In fact, upstream has no known solution to this problem.
- This method doesn't work on Linux with existing glibc implementations because the
We have internally also discussed the second problem of waking a non-RT thread from a RT thread (and vice versa, or even RT-to-RT signaling). Our thought process on it is as follows:
- The lack of support of priority inheritance on condition variables and semaphores in glibc paints a grim picture, as we cannot use standard library functions to implement such a framework. There's librtpi which implements a real-time-safe condition variable. However, it is licensed under LGPL, which makes it more difficult to use for closed-source applications. Since it is not owned by us, this would be hard to relicense for closed-source applications (like we can do for cactus-rt).
- There are also methods to avoid livelock and CPU usage associated with spin wait, but this is also hard to implement and not suitable for all purposes.
These imply it will be difficult for us to create a generally-applicable interface for this in cactus-rt, which is supposed to generally support 1000Hz hard-real-time applications without too many gotchas. It's likely better, at this time, for applications to pick one of the above solutions and understand the tradeoff being made. In the future where more low-level libraries are available, we may revisit this stance.
lu-maca
Hi all,
let's say I have two threads, one RT and the other non RT and the latter shall wait for an event from the first. Are you planning to introduce a generic "signal handling" module in the framework? At the moment, as far as I can see, only some termination signals can be handled.
Thanks :) Luca