5 ms·
Cooperative multitasking in embedded has to be the worst idea ever. Anyone who has done any serious work in embedded systems will tell you how bad is it when a
by 0xfedbee 3y ago
Cooperative multitasking in embedded has to be the worst idea ever. Anyone who has done any serious work in embedded systems will tell you how bad is it when a faulty task blocks everything. Please stop advertising async in embedded.
- junon 3y ago... anything faulty in an embedded world can block the chip. This is why watchdog timers exist. Async does not shut off watchdog. Not sure what your point is.
- kevin_thibedeau 3y agoWatchdogs shouldn't be triggered in the normal course of events. They are a last line of defense for exceptional circumstances that will render a device inoperative, not a cure-all for poor system design.
- rcxdude 3y agoSure, but a system where a task has ceased to execute is in pretty much all circumstances a system where the watchdog (or some other assert) should trigger. (the whole toyota case involved them getting raked over the coals because their system did not in fact detect a failed task and do this).
- junon 3y agoI... know. I'm saying that a stalled chip is a stalled chip. I don't know why async would stall your chip randomly unless you had a bug, which would stall the chip anyway.
- jacquesm 3y agoThink of a watchdog timer in the same way you think about that big red handle on a train, 'emergency use only, abuse will be punished'.
- RealityVoid 3y agoYou have a task. You do an infinite loop in the task. The task is now blocking lower prio tasks in the RTOS. If the task is broken, it's broken.
- junon 3y agoI know what a watchdog timer is. I don't see how your point refutes mine. A stall is a stall. Async doesn't change that.
- 0xfedbee 3y agoAs I said, anyone with serious embedded experience will understand my point. People who think triggering watchdog is a normal thing won’t.
- MarkMarine 3y agoYikes, no kidding. Triggering a watchdog is a “stop the dev cycle and everyone figure out what show-stopping bug is lurking in our code” time. I have no desire to use embedded rust async, I use C++ with none of the allocating containers, and honestly it’s more of a C with classes style than modern C++, plus FreeRTOS in my production embedded code. I would happily trade out C++ for the memory safety of rust. I would pick up a lightweight RTOS written in non-async rust if one existed and I could have faith in it, but other than personal projects I can’t advocate for building a hardware project on something like this yet.
- junon 3y agoI never said that, please stop the "no true scotsman" tone. I'm aware of what a watchdog timer is and what its purpose is. My point is that async doesn't introduce stalls unless you have a bug - a bug that could introduce a stall anyway. I don't see how async changes that. I write firmware and operating systems for a living, by the way.
- fleventynine 3y agoIt really comes down to memory requirements. If you can afford to give every task it's own stack and dispatch it directly from prioritized interrupts, that's great. Even better if you can use memory protection hardware to isolate the tasks from each other. But if you have many long running tasks that only need to keep a handful of bytes of state when they're waiting, a mechanism like rust async can allow for huge memory savings while mostly retaining the same code style as stackful tasks. And you can even use both approaches in the same program, with isolated stacks for realtime critical tasks and cooperative state machines for everything else.
- blackbeans 3y agoActually I never found cooperative multitasking a real issue. You don't want faulty tasks in your embedded application anyway. With cooperative multitasking it at least is easy to spot which task is the culprit. If I understand the article correctly, it seems that in this case the multitasking also isn't controlled by calling yield in custom user code, but rather always from the implementation that makes async/await work.
- jacquesm 3y ago> You don't want faulty tasks in your embedded application anyway. Faults are a way of life in software, they are unavoidable because each and every piece of software rests on a bunch of assumptions and if any one of those or a combination of them do not hold then you have a fault. Failure to envision that fault and a way to deal with it in embedded systems can cause damage to property, injury and loss of life. None of this is simple, not in theory and definitely not in practice.
- rcxdude 3y agoSure, but an RTOS doesn't help you much with safety critical guarantees. When you're worrying about that you're also worrying about redundancy of the hardware your software is running on, for example. The only thing that an RTOS is really helpful for is making it a bit easier to argue that some realtime guarantees can be met even if other code running on the device may have worst-case runtimes longer than your deadline (this doesn't really become a mitigation for a truly defective task, though, since at that point all bets are off unless you have some good task isolation). But this is not all embedded systems, not even all safety-critical ones, and there are other solutions available if you are not using an RTOS which can give you the same or better options in that case(like placing the critical code in a high-priority interrupt handler, for example).
- jacquesm 3y agoIf at all possible for such stuff I would use an FPGA and not software.
- dist1ll 3y agoThere are many domains in embedded. You're probably referring to safety-critical and hard real-time contexts? Because cooperative multitasking is bog-standard in OS kernels.