Hacker News Reader

Comment by 0xfedbee | Hacker News Reader

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.

View on HN

It 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.

... 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.

Watchdogs 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.

Sure, 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).

I... 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.

Think 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'.

You 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.

I 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.

As I said, anyone with serious embedded experience will understand my point. People who think triggering watchdog is a normal thing won’t.

Yikes, 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.

I 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.

Actually 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.

> 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.

Sure, 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).

If at all possible for such stuff I would use an FPGA and not software.

The WLCSP Lattice FPGAs are waiting for you! Only 2€ a pop for 1k LUTs!

> With cooperative multitasking it at least is easy to spot which task is the culprit.

Yeah I would love to spot that my car’s LED task is faulty while trying to brake on a 100mph highway.

Judging by your pushy comments throughout this thread I'm not really convinced you know what Rust async actually does.

There 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.

Reply on news.ycombinator.com