5 ms·

Reading the article made me think again about realtime software/hardware/OS, which I absolutely never understood. One one hand Wikipedia says "Real-time progra

Reading the article made me think again about realtime software/hardware/OS, which I absolutely never understood. One one hand Wikipedia says "Real-time programs must guarantee response within specified time constraints, often referred to as "deadlines"." ( https://en.wikipedia.org/wiki/Real-time_computing https://en.wikipedia.org/wiki/Real-time_computing ) On the other hand when I read Wikipedia's article "Real-time operating system" ( https://en.wikipedia.org/wiki/Real-time_operating_system https://en.wikipedia.org/wiki/Real-time_operating_system ) my overall understanding is that there is no feature allowing a program/thread/function to enforce e.g. "I have to be executed within 3 milliseconds" nor that that would anyway be enforced by the OS at any cost (scheduler will prioritize higher-priority tasks). Am I missing something? Or maybe the statement "Real-time programs must guarantee response within specified time constraints" must be taken literally and the program/thread/function must be written in a way that when some timer expires (and a "terminate"-event is sent to it), it will stop doing whatever it's doing (and it will potentially send back some kind of (partial) result)? As you can see, this theme confuses me :) [EDIT: thank you guys! :) ]

marcosdumay 8y ago
Real time OSes have an all or nothing response to real time tasks. They either take it to run on the specified time, or they fail with some error. The OSes also take into their hands to enforce that the tasks will finish at the time they asked for. What means that they either terminate by themselves, or the OS will terminate them, again with some explicit error.
- zepearl 8y ago
  Thx but well, this kind of goes frontally against the other 2 answers I got (I understood that nothing ever gets explicitly terminated by the OS and I felt happy with that approach as it kind of made sense to me, but some now strong doubts are coming back again...).
  - gizmo686 8y ago
    Realtime doesn't mean error free. A realtime OS might provide some form of a watchdog feature where it can detect when a program fails to meet its deadline. Think of it like a segfault in a traditional system. If everyone did their job correctly, it would never come up, but people make mistakes and it is better to detect them and fail in a controlled manner than it is not notice and fail in unpredictable ways.
  - marcosdumay 8y ago
    Oh, I've read them now. There are some answers about something we used to call "soft real time". Those OSes (Linux was one, for a while, it's not anymore) will have some processes marked as real time, and change the scheduling so that they will execute right at the correct moments. The gotcha is that there can not be many real time processes, since the OS has no way to resolve a conflict between them. What I described is called "hard real time". It is indeed a very different thing. Both kinds of OSes are in current use, on different niches.
adrianratnapala 8y ago
OSes and applications that get called real-time vary a lot. But yes, when it is meant rigorously, you can definitely schedule a thing to run on exactly at particular times, preempting whatever lower priority thing was running before. In my last embedded project that meant we had thing that got called every 64 microseconds -- and it was our job to ensure it finished in time for the next tick and also left enough CPU for all the other threads.
- zepearl 8y ago
  Thx >>and it was our job to ensure it finished in time for the next tick and also left enough CPU for all the other threads Then, for the realtime program to run correctly, it would involve as well an understanding of all other processes/programs that are running at potentially the same time (e.g. "competitors" and "collaborators") and/or with the same or higher priorities, etc.., right? Therefore, candidate summarized definition: realtime (HW?/)OSs allow you to execute SW which will run with no interruption, as long as no other SW having the same or higher level of priority interferes? Does it sound right?
  - FigBug 8y ago
    Yes, you need to understand all the other processes, but in most cases, there are no other processes. You are writing everything the system is doing. It's up to you to determine what is running in each thread and set it's priority appropriately so that each thread has enough time to run. Real time OSes give you complete control. What you do with that control is up to you based on your needs.
    - zepearl 8y ago
      >>but in most cases, there are no other processes Cool (yes, I was wondering about the complexity :) ) Thank you!
  - adrianratnapala 8y ago
    > Then, for the realtime program to run correctly, it would involve as well an understanding of all other processes/programs that are running at potentially the same time Yes, and the best way to understand things is to keep them simple. For example you can haveone real time thread which gets absolute priority and meets hard deadlines while everything else runs whenever the OS can find time for it. Then your only two rules are (1) don't let the real-time thread starve the others completely, and (2) don't rely on timing from anything except the real-time thread. > OSs allow you to execute SW which will run with no interruption, as long as no other SW having the same or higher level of priority interferes? Yep. Any OS meeting that definition is real-time. Probably you could get away with a looser definition, but getting it right would be a rabbit-hole.
gizmo686 8y ago
Generally real-time systems are realtime at every level. The idea is that you don't have a situation where you need to send a terminate event, because the program would have already terminated. The point of a realtime OS is not to make your programs run in real-time, but to make it possible for your programs to run in real-time. This is simply not possible on a general OS like Linux, because the kernel can always to do something else while your program is running. Consider the software that drives the printhead in your printer. The timing here is critical. If a command gets sent too early or too late, the print will not come out right. You probably don't want the OS to be what tells you to send a command every hundred millisecond. Getting this timing right is a core feature of your application, all you need from the OS is to not get in the way of your getting the timing right. If you are in a state where you need to send a partial result then the program computing the result is likely not really realtime.
- zepearl 8y ago
  Thx >>The point of a realtime OS is not to make your programs run in real-time, but to make it possible for your programs to run in real-time. So basically, if I program something and somehow set it to be "realtime" then I can be sure that it won't be suspended before it finishes whatever it is doing? Such a condition cannot be kept indefinitely - soon or later there will be activities that will need the OS' attention (therefore my program will have to be suspended), no? (If yes then I have problems understanding the threshold...).
  - alfalfasprout 8y ago
    This varies. On a multicore CPU it's possible that processes will actually be pinned to a core and those processes will have exclusive access to the CPU core (i.e nothing else will be scheduled on it). Real-time programs tend to avoid syscalls, etc. which cause a context switch so it is indeed possible to run a realtime program indefinitely without the OS stepping in. It's tricky though because even things like dynamic memory allocation can have non-realtime behavior.
    - zepearl 8y ago
loeg 8y ago
> nor that that would anyway be enforced by the OS at any cost (scheduler will prioritize higher-priority tasks). When sorted against ordinary time-sharing program priorities, any real-time task is a higher priority.
pdkl95 8y ago
A practical example I once had to solve: I was writing the BIOS/flash-loader/debugger code for a Z80 clone[1] we made. The compiler send instruction packets over the RS-232 serial port at 115200 kBd (kbaud). Using 8N1, this is 12800 B/s which means we have a deadline to read the current byte out of the serial port register ever 78us or data will be lost as the new incoming byte on the serial port is written to the port's IO register. This sounded like a lot of time, until I was informed some of the boards we sold ran at (iirc) 128kHz. After accounting for memory access time and the runtime of relevant instructions, it worked out that we had at most a budget of 60-70 instructions/byte, which wasn't anywhere close to enough to process the byte (including a simple checksum). Even using a normal ISR wasn't possible: the usual register push/pop would have a major portion of our instruction budget. I ended up dedicating a set of registers to receiving the bytes in realtime into as buffer, while processing the data non-realtime using the remaining registers. Depending on how strict your deadlines are, "realtime" can mean accounting for every clock cycle the CPU is running. An OS (realtime or otherwise) is for people with softer deadlines and CPU time to spare. [1] https://en.wikipedia.org/wiki/Rabbit_2000 https://en.wikipedia.org/wiki/Rabbit_2000

marcosdumay 8y ago

Real time OSes have an all or nothing response to real time tasks. They either take it to run on the specified time, or they fail with some error. The OSes also take into their hands to enforce that the tasks will finish at the time they asked for. What means that they either terminate by themselves, or the OS will terminate them, again with some explicit error.

zepearl 8y ago
Thx but well, this kind of goes frontally against the other 2 answers I got (I understood that nothing ever gets explicitly terminated by the OS and I felt happy with that approach as it kind of made sense to me, but some now strong doubts are coming back again...).
- gizmo686 8y ago
  Realtime doesn't mean error free. A realtime OS might provide some form of a watchdog feature where it can detect when a program fails to meet its deadline. Think of it like a segfault in a traditional system. If everyone did their job correctly, it would never come up, but people make mistakes and it is better to detect them and fail in a controlled manner than it is not notice and fail in unpredictable ways.
- marcosdumay 8y ago
  Oh, I've read them now. There are some answers about something we used to call "soft real time". Those OSes (Linux was one, for a while, it's not anymore) will have some processes marked as real time, and change the scheduling so that they will execute right at the correct moments. The gotcha is that there can not be many real time processes, since the OS has no way to resolve a conflict between them. What I described is called "hard real time". It is indeed a very different thing. Both kinds of OSes are in current use, on different niches.

adrianratnapala 8y ago

OSes and applications that get called real-time vary a lot. But yes, when it is meant rigorously, you can definitely schedule a thing to run on exactly at particular times, preempting whatever lower priority thing was running before. In my last embedded project that meant we had thing that got called every 64 microseconds -- and it was our job to ensure it finished in time for the next tick and also left enough CPU for all the other threads.

zepearl 8y ago
Thx >>and it was our job to ensure it finished in time for the next tick and also left enough CPU for all the other threads Then, for the realtime program to run correctly, it would involve as well an understanding of all other processes/programs that are running at potentially the same time (e.g. "competitors" and "collaborators") and/or with the same or higher priorities, etc.., right? Therefore, candidate summarized definition: realtime (HW?/)OSs allow you to execute SW which will run with no interruption, as long as no other SW having the same or higher level of priority interferes? Does it sound right?
- FigBug 8y ago
  Yes, you need to understand all the other processes, but in most cases, there are no other processes. You are writing everything the system is doing. It's up to you to determine what is running in each thread and set it's priority appropriately so that each thread has enough time to run. Real time OSes give you complete control. What you do with that control is up to you based on your needs.
  - zepearl 8y ago
    >>but in most cases, there are no other processes Cool (yes, I was wondering about the complexity :) ) Thank you!
- adrianratnapala 8y ago
  > Then, for the realtime program to run correctly, it would involve as well an understanding of all other processes/programs that are running at potentially the same time Yes, and the best way to understand things is to keep them simple. For example you can haveone real time thread which gets absolute priority and meets hard deadlines while everything else runs whenever the OS can find time for it. Then your only two rules are (1) don't let the real-time thread starve the others completely, and (2) don't rely on timing from anything except the real-time thread. > OSs allow you to execute SW which will run with no interruption, as long as no other SW having the same or higher level of priority interferes? Yep. Any OS meeting that definition is real-time. Probably you could get away with a looser definition, but getting it right would be a rabbit-hole.

gizmo686 8y ago

Generally real-time systems are realtime at every level. The idea is that you don't have a situation where you need to send a terminate event, because the program would have already terminated. The point of a realtime OS is not to make your programs run in real-time, but to make it possible for your programs to run in real-time. This is simply not possible on a general OS like Linux, because the kernel can always to do something else while your program is running. Consider the software that drives the printhead in your printer. The timing here is critical. If a command gets sent too early or too late, the print will not come out right. You probably don't want the OS to be what tells you to send a command every hundred millisecond. Getting this timing right is a core feature of your application, all you need from the OS is to not get in the way of your getting the timing right. If you are in a state where you need to send a partial result then the program computing the result is likely not really realtime.

zepearl 8y ago
Thx >>The point of a realtime OS is not to make your programs run in real-time, but to make it possible for your programs to run in real-time. So basically, if I program something and somehow set it to be "realtime" then I can be sure that it won't be suspended before it finishes whatever it is doing? Such a condition cannot be kept indefinitely - soon or later there will be activities that will need the OS' attention (therefore my program will have to be suspended), no? (If yes then I have problems understanding the threshold...).
- alfalfasprout 8y ago
  This varies. On a multicore CPU it's possible that processes will actually be pinned to a core and those processes will have exclusive access to the CPU core (i.e nothing else will be scheduled on it). Real-time programs tend to avoid syscalls, etc. which cause a context switch so it is indeed possible to run a realtime program indefinitely without the OS stepping in. It's tricky though because even things like dynamic memory allocation can have non-realtime behavior.
  - zepearl 8y ago

loeg 8y ago

> nor that that would anyway be enforced by the OS at any cost (scheduler will prioritize higher-priority tasks). When sorted against ordinary time-sharing program priorities, any real-time task is a higher priority.

pdkl95 8y ago

A practical example I once had to solve: I was writing the BIOS/flash-loader/debugger code for a Z80 clone[1] we made. The compiler send instruction packets over the RS-232 serial port at 115200 kBd (kbaud). Using 8N1, this is 12800 B/s which means we have a deadline to read the current byte out of the serial port register ever 78us or data will be lost as the new incoming byte on the serial port is written to the port's IO register. This sounded like a lot of time, until I was informed some of the boards we sold ran at (iirc) 128kHz. After accounting for memory access time and the runtime of relevant instructions, it worked out that we had at most a budget of 60-70 instructions/byte, which wasn't anywhere close to enough to process the byte (including a simple checksum). Even using a normal ISR wasn't possible: the usual register push/pop would have a major portion of our instruction budget. I ended up dedicating a set of registers to receiving the bytes in realtime into as buffer, while processing the data non-realtime using the remaining registers. Depending on how strict your deadlines are, "realtime" can mean accounting for every clock cycle the CPU is running. An OS (realtime or otherwise) is for people with softer deadlines and CPU time to spare. [1] https://en.wikipedia.org/wiki/Rabbit_2000 https://en.wikipedia.org/wiki/Rabbit_2000