I have couple questions regarding setting signals to inactive threads using RTX and CMSIS. Please see the example code below:
osThreadId thread_id = osThreadCreate(osThread(thread_body), NULL); /* set thread active */
osThreadTerminate(thread_id); /* set thread inactive */
osSignalSet(thread_id, 1); /* set signal to inactive thread */
osThreadCreate(osThread(thread_body), NULL); /* set same thread active again */
void thread_body (void const * arg) { osSignalWait(1, 0); /* is the signal set? */ }
Questions: 1) The signal is set while the thread is inactive. What is the effect of this? 2) In the thread_body function, will the signal be set?
Thank you
If you are doing a panic stop after getting a sensor error or someone have pressed a stop button, then you could kill all threads. But you then shouldn't expect to be able to recover from that state. So have the panic code rewrite the state of every I/O pin of the chip to turn off power, short-circuits motors as electrical breaks etc and then wait for an operator to reset the device and then potentially on reboot wait for a key lock activation before limping back to "home position" to do a full self-test before you are ready to start up normal operation again.
Any time you kill a thread, you are violating any known/documented state information for that thread and potentially an unknown number of global variables/hardware. And if the kill comes from a thread of same or higher priority so the kill need not happen in a wait function, you might also violate code-generation or logic rules of the programming language or the runtime library.
If you have any plan at all for returning to normal operation without rebooting, then you really shouldn't kill threads but should spend the time/code to teach them how to always respond to ordered thread-stop events.
Think again about that magical teleportation. It would be "safe" if it always teleported you to a known safe state. So you always ended up in a bed at a safe place. If it instead only manages a horizontal translation, and you happened to start from the eight floor of a building, you might end up with a quite long fall when you got teleported into thin air eight floors above the "rallying point". Killing a thread leaves you in an unknown state where you do not know what is needed to recover. It is a "crash out" function, where only a reset has a contractual obligation to return you to a known state.
I have found a complete and elegant solution to the problem of “waking up” a thread that can pend on several different os events - the CMSIS osWait function. If this function were used for pending, it would be simple to send an asynchronous “halt event” to a thread no matter what its pending on, even a timeout. The thread could then handle the event and any necessary cleanup. No terminating of threads required.
Only problem is, the CMSIS osWait function is optional and RTX doesn’t support it. Why doesn’t RTX support osWait? This seems like an extremely useful function. Can it be added?
Thanks,
Ben