3 ms·

Deterministic programs are great, but that's not a prerequisite for hard realtime. A hard realtime system only needs to be guaranteed to satisfy a schedule.

jacquesm 4y ago
I read that as 'deterministic within the context of the hard real time portion' and that is a prerequisite otherwise you may end up overrunning your slot leading to a possible cascade of problems.
- naasking 4y ago
  It's not a prerequisite in that case either, as long as all possible execution paths fall within the time budget you're fine. Making the execution path deterministic is one way to do that and makes analysis simpler, but it's not the only way.
  - jacquesm 4y ago
    A single loop with an undetermined end condition and you're toast. So that's why having deterministic behavior is a thing to strive for because it allows you to make a guarantee. If all of your code paths are 'straight through' you just tally up the longest sections and if that's below your budget then you know you are going to be ok in all situations.
    - pgorczak 4y ago
      … if you’re running a single task at a time. Usually multiple tasks need exclusive access to shared resources. And they might be triggered by external inputs which are non-deterministic, making the number of possible system states you need to check intractable.
      - jacquesm 4y ago
        Yes, hard real time is hard. So don't multi-task, use as simple a scheduler as you can afford and make sure all your time critical paths are limited. I've built quite a few hard real time systems (machine control, mostly) and the penalty for messing that up would be either a toolstrike, loss of a workpiece, loss of a machine or loss of limb or life so I'm aware of the pitfalls and would definitely not want a multi-tasking OS as the core for anything hard real time. For soft real time that works fine, but for hard real time you need absolute control. In an extreme case that can mean a separate CPU running with all interrupts disabled (and NMI tied) so that you will never be surprised. Another CPU can handle concurrent stuff.
        keithnz 4y ago
        I've also done a bunch of machine control, and I generally really like the multi CPU architecture for real time control, if you are making your own hardware, I don't think it is too extreme. I've also found a lot of the systems end up being a mix of hard/soft realtime, where the bits that directly monitor/control the machine are hard, and then there is soft "decision" type stuff, farming them out to their own CPUs is often much easier to make guarantees of the hard real time bits.

jacquesm 4y ago

I read that as 'deterministic within the context of the hard real time portion' and that is a prerequisite otherwise you may end up overrunning your slot leading to a possible cascade of problems.

naasking 4y ago
It's not a prerequisite in that case either, as long as all possible execution paths fall within the time budget you're fine. Making the execution path deterministic is one way to do that and makes analysis simpler, but it's not the only way.
- jacquesm 4y ago
  A single loop with an undetermined end condition and you're toast. So that's why having deterministic behavior is a thing to strive for because it allows you to make a guarantee. If all of your code paths are 'straight through' you just tally up the longest sections and if that's below your budget then you know you are going to be ok in all situations.
  - pgorczak 4y ago
    … if you’re running a single task at a time. Usually multiple tasks need exclusive access to shared resources. And they might be triggered by external inputs which are non-deterministic, making the number of possible system states you need to check intractable.
    - jacquesm 4y ago
      Yes, hard real time is hard. So don't multi-task, use as simple a scheduler as you can afford and make sure all your time critical paths are limited. I've built quite a few hard real time systems (machine control, mostly) and the penalty for messing that up would be either a toolstrike, loss of a workpiece, loss of a machine or loss of limb or life so I'm aware of the pitfalls and would definitely not want a multi-tasking OS as the core for anything hard real time. For soft real time that works fine, but for hard real time you need absolute control. In an extreme case that can mean a separate CPU running with all interrupts disabled (and NMI tied) so that you will never be surprised. Another CPU can handle concurrent stuff.
      - keithnz 4y ago
        I've also done a bunch of machine control, and I generally really like the multi CPU architecture for real time control, if you are making your own hardware, I don't think it is too extreme. I've also found a lot of the systems end up being a mix of hard/soft realtime, where the bits that directly monitor/control the machine are hard, and then there is soft "decision" type stuff, farming them out to their own CPUs is often much easier to make guarantees of the hard real time bits.