Thanks for your answers, I created a module with a single real-time thread and gradually increased its period. Victor was right: Linux becomes less responisve but the computer does not crash. > I don't think your hypothesis is correct. Try running a single thread at > increasing rates and see what happens. It should just make the base Linux > OS less and less reliable.
I found that the thread does not preempt itslef but it is invoked when the previous cycle terminates. Thus, if the thread duration is longer than the thread period, the thread will not be invoked in real-time but with an offset. >While AFAIK there's no way to prevent it from occurring through the RTLinux >kernel, there are several ways to have your own thread detect the >situation. The most basic is to construct a mutex whose state is "set" >when a thread starts and "reset" when it ends. Then if your thread starts >and finds it "set", it can terminate immediately. This suggestion seems not work since as far as I have observed the thread does not preempt itself and it will terminate reseting the mutex before it is invoked again. Therefore the mutex will always be set when it is checked. In case it is of any use to anyone the solution I have used is to create a second thread (watchdog) with higher priority and the same period as the real-time thread. The real-time thread decreases a counter by one and the watchdog increases it also by one. If this counter is larger than one it means that the real-time thread duration is longer than its period (the watchdog is being invoked more often than the thread) and therfore the process has to terminate since real-time constraints can no longer be met. I hope this makes sense. thanks again Raul -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
