3 ms·

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 part

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.

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.