Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fearless concurrency in your microcontroller

blog.japaric.io

Post reply on HN
Print view View original

41–50 of 52 posts

Re: Fearless concurrency in your microcontroller

#41

Post by PerLindgrenRTFM »

mechatrocity wrote: post #22

> The RTFM language was created ... to develop real time systems for which FreeRTOS didn’t fit the bill. I'm curious how they determined FreeRTOS wasn't appropriate for their use cases?

Hi There. A number of factors. 1) FreeRTOS is ineffective, in many cases you have to code around the kernel to get sufficiently good response times. 2) FreeRTOS does not offer any means to schedulability analysis, as the internal overhead is very hard to predict and data dependent (and lacks proper characterisation). 3) The threading model as such is not particularly suited to concurrent programming (RTFM is event driven, reflecting the reactive nature of the hardware as well as the application). 4) Thread based programming is hard to get right, see e.g., https://www2.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-...). 5) Regarding FreeRTOS, the current license disallows to make comparisons with FreeRTOS without their permission, how about that for starters!!! /Per

Re: Fearless concurrency in your microcontroller

#42

Post by PerLindgrenRTFM »

Animats wrote: post #37

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…

"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

Re: Fearless concurrency in your microcontroller

#43

Post by PerLindgrenRTFM »

nickpsecurity wrote: post #31

Neat to see given I submitted RTFM-core recently: https://news.ycombinator.com/item?id=14294408 So, the author learned from it, ported it to a safer language, and release the results. Although Ada/SPARK Ravenscar did embedded concurrency, the author certainly builds on modern methods for achieving similar (possibly better) results in Internet of Things. Good work. :)

Thanks! RTFM-core embeds C code, and is as such not particularly safe. However, as an experiment an object (component like) abstraction RTFM-cOOre was drafted (along with a prototype implementation). The cOOre language "could" be safe (just using rtfm-core/C as an intermediate representation). But developing and "selling" a new language requires huge amount effort and resources. Many of the sought features for the cOOre language are already in place with Rust (just that the concurrency model was not there). So that is where it all started, RTFM for Rust, is at present just a subset of the rtfm-core language, but extensions towards timing semantics and object orientation are already in the making. Disclaimer: Myself being fairly new to Rust, so all the Rust type system wizardry is due Mr. Japaric. /Per

Re: Fearless concurrency in your microcontroller

#44

Post by touisteur »

pjmlp wrote: post #24
pdelbarba wrote: post #14

Earlier quoted context omitted.

No offense, but nobody in their right mind is going to use any of this in a production environment. For instance, what will your hypersonic rocket do while garbage collection is running instead of it's real-time control loops?

I guess the French and US military using Aonix real time JVMs for weapons control and monitoring are the right set of persons to answer your question. Also some military think memory leaks are irrelevant on missiles, given the ultimate garbage collector.

Well it all depends how 'hard' your real-time is. If you go with Atego/aonix, you can get down to almost-C-Ada-like latencies but be ready to change your java coding style. Sliced-time GC works OK until you put too much pressure on it (concatenating logging strings that you're not going to record or display... allocating tons of small objets for local uses... Programming in 'Classic' java...) and it can't clean up fast enough... In the end you code in a small and sad watered down subset of java... I mean : java is everything (almost, except for primitive types) on the heap ! Avoid java collections (use javolution or hppc-rt instead), avoid auto-boxing, no local allocation, no String concatenation, no Selector API ('select' in java nio...) because it allocates like mad... God help you if you need to stream some amount of data via TCP. And be prepared to spend some time to fine tune the GC. You also take a hit on performance and compilation time compared to hotspot (you need aot compilation for real-time, the java runtime seems not as optimised... Not as many man-decades of work on it).

All in all I'd rank it 'easier' than C in developer comfort and proficiency but frankly, if you don't do C, I'd just go directly to Ada...

Re: Fearless concurrency in your microcontroller

#45

Post by nickpsecurity »

touisteur wrote: post #40
nickpsecurity wrote: post #34

Earlier quoted context omitted.

It's called real-time, garbage collection. It occurs predictably on regular intervals before enough leaks happen to blow missiles up or whatever other tragedy. Aonix and some other vendors have had it for a long time now. Meanwhile, mainstream found out in the past, few years that Go could achieve "low-latency" garbage collection. The field can do more than many of them think given the countless person-years invested…

Seems AdaCore is working to add some form of borrow-checker to Spark :-) https://cps-vo.org/node/34575

I don't see anything about safety for dynamic, memory management in that link. It just talks about correctness. I'm specifically wanting affine types and ownership system that let SPARK go from static to dynamic.

I do like them splitting it into several levels, though. That worked under Orange Book for security.

Re: Fearless concurrency in your microcontroller

#46

Post by pjmlp »

touisteur wrote: post #44
pjmlp wrote: post #24

Earlier quoted context omitted.

I guess the French and US military using Aonix real time JVMs for weapons control and monitoring are the right set of persons to answer your question. Also some military think memory leaks are irrelevant on missiles, given the ultimate garbage collector.

Well it all depends how 'hard' your real-time is. If you go with Atego/aonix, you can get down to almost-C-Ada-like latencies but be ready to change your java coding style. Sliced-time GC works OK until you put too much pressure on it (concatenating logging strings that you're not going to record or display... allocating tons of small objets for local uses... Programming in 'Classic' java...) and it can't clean up fa…

Thanks for telling your Aonix experience.

I would just argue that un these domains 'Classical C' isn't used, given the constraints regarding language features, using stuff like MISRA-C and similar.

Fully agree with Ada comment, even better if using SPARK.

In any case, many military seem more focused on being easy to hire recruits that already know how to program than training them, hence the ramping up of Java adoption.

Re: Fearless concurrency in your microcontroller

#47

Post by pjmlp »

nickpsecurity wrote: post #45
touisteur wrote: post #40

Earlier quoted context omitted.

Seems AdaCore is working to add some form of borrow-checker to Spark :-) https://cps-vo.org/node/34575

I don't see anything about safety for dynamic, memory management in that link. It just talks about correctness. I'm specifically wanting affine types and ownership system that let SPARK go from static to dynamic. I do like them splitting it into several levels, though. That worked under Orange Book for security.

AdaCore hired the guy that designed ParaSail, however the language development is a bit slow.

https://forge.open-do.org/plugins/moinmoin/parasail/FrontPag...

Re: Fearless concurrency in your microcontroller

#48

Post by touisteur »

nickpsecurity wrote: post #45
touisteur wrote: post #40

Earlier quoted context omitted.

Seems AdaCore is working to add some form of borrow-checker to Spark :-) https://cps-vo.org/node/34575

I don't see anything about safety for dynamic, memory management in that link. It just talks about correctness. I'm specifically wanting affine types and ownership system that let SPARK go from static to dynamic. I do like them splitting it into several levels, though. That worked under Orange Book for security.

My bad, slides are not available yet... There's a mention in there about some rust-like ownership proof mechanism in their roadmap. I thought about our last exchange on SPARK & rust when I saw this :-).

Re: Fearless concurrency in your microcontroller

#49

Post by touisteur »

pjmlp wrote: post #46
touisteur wrote: post #44

Earlier quoted context omitted.

Well it all depends how 'hard' your real-time is. If you go with Atego/aonix, you can get down to almost-C-Ada-like latencies but be ready to change your java coding style. Sliced-time GC works OK until you put too much pressure on it (concatenating logging strings that you're not going to record or display... allocating tons of small objets for local uses... Programming in 'Classic' java...) and it can't clean up fa…

Thanks for telling your Aonix experience. I would just argue that un these domains 'Classical C' isn't used, given the constraints regarding language features, using stuff like MISRA-C and similar. Fully agree with Ada comment, even better if using SPARK. In any case, many military seem more focused on being easy to hire recruits that already know how to program than training them, hence the ramping up of Java adopti…

Well the argument seems to be that it's easier to hire 'experienced' java developers (hear: have 'java' on their resume...). But the people you get are for the most part either inexperienced (fresh out of school) or you have to break all their classic-java muscle memory. Not sure about the tradeoff here, when you compare training in Ada/SPARK.

You're right about Misra C. Even with Ada you'll end up banning dynamic memory allocation and some stack-exploding stuff, but you still have alternatives like storage pools ('looks-like-dynamic' memory allocation) and Controlled types, and at least you get a stack for structured data types and not just for primitive types...

Re: Fearless concurrency in your microcontroller

#50

Post by nickpsecurity »

touisteur wrote: post #40
nickpsecurity wrote: post #34

Earlier quoted context omitted.

It's called real-time, garbage collection. It occurs predictably on regular intervals before enough leaks happen to blow missiles up or whatever other tragedy. Aonix and some other vendors have had it for a long time now. Meanwhile, mainstream found out in the past, few years that Go could achieve "low-latency" garbage collection. The field can do more than many of them think given the countless person-years invested…

Seems AdaCore is working to add some form of borrow-checker to Spark :-) https://cps-vo.org/node/34575

In case you're interested, here was a reply from Yannick at AdaCore:

https://groups.google.com/d/msg/comp.lang.ada/H35QcYiWR1Y/jJ...

It seems they're adding a little bit of it for SPARK but not critical, dynamic part. I asked him at the end if they plan to go full, dynamic safety for full Ada if the SPARK experiment succeeds. Awaiting the reply.

Post reply on HN