7 ms·

>> If the system does not have hard realtime requirements and has a decent resources, why wouldn't you trust Haskell? Because that doesn't describe cars, a jet

>> If the system does not have hard realtime requirements and has a decent resources, why wouldn't you trust Haskell? Because that doesn't describe cars, a jet, space shuttles, or ... well anything I'd trust my life to. Hell, Haas CNCs still run DOS 8.0

comex 13y ago
Yeah, I would avoid trusting something hard-realtime to a language with lazy evaluation and garbage collection, even if it's quite trustworthy for other purposes. (IIRC, these programs don't even use malloc, let alone garbage collection :)
- akiselev 13y ago
  MISRA discourages use of malloc (because you can deviate with clear documentation as to why) but it's not at all unheard of. That said, many embedded systems don't come with a usable implementation of malloc so the safe default is to write your own memory manager (safer but not always possible: use a well tested one) that uses static memory pools to allocate dynamic memory.
  - userbinator 13y ago
    Any time you're using malloc() you run the risk of running out of memory, which is a very very bad thing for a safety-critical embedded system. Statically allocated, fixed-size things are good, as are algorithms that are designed not to require O(n) space to perform their processing.
wyager 13y ago
There are many safety-critical systems that aren't hard realtime. Radio transponders, human interface systems, life support systems. In fact, I'd say a great way to do it would be to implement all the hard realtime bits in some low-level, pain-in-the-ass language like Ada and then wrap all that unpleasant stuff in a high-level language that is very unfriendly to implementation bugs (like Haskell).
- jeffdavis 13y ago
  "There are many safety-critical systems that aren't hard realtime." I'm not convinced you can make such a clean separation.
- akiselev 13y ago
  >> Radio transponders, human interface systems, life support systems. Don't think you know what a hard real time system is. Both radio transponders and life support systems have to be hard real time. Motors and antennas don't magically communicate with your userland "apps," they're controlled by precisely timed code. The "human interface systems" (could you have brought to the conversation a more generic term?) to all of these are often, too, hard real time because that's the easiest way to prove something is safe and test the edge cases. For all intents and purposes, anything "soft real time" has a kernel and kernels are monolithic disasters waiting to happen for anyone who needs timing guarantees (hint: if your life depends on it, it needs timing guarantees). On top of that is the unfriendliness of Haskell to the real world of hiring (and this is Boeing for godzilla's sake) and it's lack of proper testing in such an environment, although I'm sure there are those who use it in embedded.
  - wyager 13y ago
    >Motors and antennas don't magically communicate with your userland "apps," they're controlled by precisely timed code. Motors and antennas are usually managed by hardware or dedicated uCs, not PFC software. Aircraft aren't running their telemetry off GnuRadio, and aircraft PFCs sure as hell aren't worrying about servo timing. "Human interface systems" I thought would be self explanatory; pilots don't care if their plane UIs take 5us or 5ms to update. They can't react on those time scales anyway. Hell, you could probably code all the user-facing avionics stuff in Javascript and be fine.
    - KMag 13y ago
      > pilots don't care if their plan UIs take 5us or 5ms to update Hard real-time doesn't mean "fast", it means having guaranteed upper bounds on response time. In order to get those guarantees, uninteruptable code paths need to be short and critical parts of the systems need to be simple, which often also leads to fast response. However, the difference between soft and hard realtime systems is the guarantees. A soft real-time system that has a 5ms mean update time but has a 1e-6 chance of taking 10 seconds is much less useful than a hard real-time system that has a 15ms mean update time with a hard upper-bound of 50ms.

comex 13y ago

Yeah, I would avoid trusting something hard-realtime to a language with lazy evaluation and garbage collection, even if it's quite trustworthy for other purposes. (IIRC, these programs don't even use malloc, let alone garbage collection :)

akiselev 13y ago
MISRA discourages use of malloc (because you can deviate with clear documentation as to why) but it's not at all unheard of. That said, many embedded systems don't come with a usable implementation of malloc so the safe default is to write your own memory manager (safer but not always possible: use a well tested one) that uses static memory pools to allocate dynamic memory.
- userbinator 13y ago
  Any time you're using malloc() you run the risk of running out of memory, which is a very very bad thing for a safety-critical embedded system. Statically allocated, fixed-size things are good, as are algorithms that are designed not to require O(n) space to perform their processing.

wyager 13y ago

There are many safety-critical systems that aren't hard realtime. Radio transponders, human interface systems, life support systems. In fact, I'd say a great way to do it would be to implement all the hard realtime bits in some low-level, pain-in-the-ass language like Ada and then wrap all that unpleasant stuff in a high-level language that is very unfriendly to implementation bugs (like Haskell).

jeffdavis 13y ago
"There are many safety-critical systems that aren't hard realtime." I'm not convinced you can make such a clean separation.
akiselev 13y ago
>> Radio transponders, human interface systems, life support systems. Don't think you know what a hard real time system is. Both radio transponders and life support systems have to be hard real time. Motors and antennas don't magically communicate with your userland "apps," they're controlled by precisely timed code. The "human interface systems" (could you have brought to the conversation a more generic term?) to all of these are often, too, hard real time because that's the easiest way to prove something is safe and test the edge cases. For all intents and purposes, anything "soft real time" has a kernel and kernels are monolithic disasters waiting to happen for anyone who needs timing guarantees (hint: if your life depends on it, it needs timing guarantees). On top of that is the unfriendliness of Haskell to the real world of hiring (and this is Boeing for godzilla's sake) and it's lack of proper testing in such an environment, although I'm sure there are those who use it in embedded.
- wyager 13y ago
  >Motors and antennas don't magically communicate with your userland "apps," they're controlled by precisely timed code. Motors and antennas are usually managed by hardware or dedicated uCs, not PFC software. Aircraft aren't running their telemetry off GnuRadio, and aircraft PFCs sure as hell aren't worrying about servo timing. "Human interface systems" I thought would be self explanatory; pilots don't care if their plane UIs take 5us or 5ms to update. They can't react on those time scales anyway. Hell, you could probably code all the user-facing avionics stuff in Javascript and be fine.
  - KMag 13y ago
    > pilots don't care if their plan UIs take 5us or 5ms to update Hard real-time doesn't mean "fast", it means having guaranteed upper bounds on response time. In order to get those guarantees, uninteruptable code paths need to be short and critical parts of the systems need to be simple, which often also leads to fast response. However, the difference between soft and hard realtime systems is the guarantees. A soft real-time system that has a 5ms mean update time but has a 1e-6 chance of taking 10 seconds is much less useful than a hard real-time system that has a 15ms mean update time with a hard upper-bound of 50ms.