Hacker News new | ask | show | jobs
by Animats 3333 days ago
That's a very nice use of Rust's safety. This tasking model is a common way to write programs for very small machines, but with this, it's safe. People have a very hard time getting all that priority-level adjustment right.

It's not concurrency, though. It's asynchrony. Two things never happen at at the same time.

Modula I for the PDP-11 did do all this in 1979. In addition, it computed the worst-case stack for each task, so you were sure you couldn't run out of memory if enough preemption occurred. Today this is mostly an issue on very low-end machines, but this code is for machines like very low end ARM processors, where you might run out of stack. Some test fixture to force worst case stack use, with all the priorities stacked up, would be useful.

1 comments

"Its not concurrency". I would argue that. Its not parallelism (at least not in the current state, but the RTFM-core language that originated this work offers true parallelism, implemented onto of Windows Threads, and Pthreads (Linux/OSX). On multicores, deadlock freeness is not guaranteed, but the rtfd-compiler detects potential deadlocks at compile time for the implementer to fix (so no spurious deadlocks from a system passing compilation). As the multicore implementation is being based on threads, response time analysis for such systems are basically out the window... (Also such multicore systems are very hard to predict, due to cashes, etc...) /Per