Hi, I was asked the question in the title some time ago. I had some real-time embedded system experience but with RTOS. A watch-dog can avoid a task not called in a real-time system. But in a RTOS, what is the right answer for it? I knew task priority, a timer triggered event all can influence a task execution. But they didn't look like the correct answer. What is the right answer do you think? Best Regards,
How to avoid a task not executed in a real-time OS?
Started by ●January 21, 2019
Reply by ●January 21, 20192019-01-21
> I was asked the question in the title some time ago. I had some real-time > embedded system experience but with RTOS. A watch-dog can avoid a task not > called in a real-time system. But in a RTOS, what is the right answer for it? > I knew task priority, a timer triggered event all can influence a task execution.It's a peculiar choice of words in asking these questions. I'm not sure exactly what you mean by "avoid". In a typically designed single core system, at least one RTOS task is always present (blocked or waiting) but not always actively doing work (running). There is always more than one task, otherwise there is no justification for using an RTOS. The programmer can (usually) start (create) and stop (kill) tasks. Task creation usually happens at init time but there's no rule the forces that design. If you want to avoid the task running state, kill the task or inhibit the input to unblock it. You decide as the programmer. Task priority is a means to direct a lower priority task to yield CPU usage while a higher priority task is running. When the high priority task is done running (that is, it blocks), the lower priority task automatically runs if it's runnable (not blocking). Task priority can delay a task running in response to what unblocked it but not inhibit it. That's a simplified answer. Some RTOS's are quite sophisticated and the answers get complicated when you use their advanced features. JJS
Reply by ●January 21, 20192019-01-21
On 2019-01-21 Robert Willy wrote in comp.arch.embedded:> Hi, > I was asked the question in the title some time ago. I had some real-time > embedded system experience but with RTOS. A watch-dog can avoid a task not > called in a real-time system. But in a RTOS, what is the right answer for it? > I knew task priority, a timer triggered event all can influence a task execution. > But they didn't look like the correct answer. What is the right answer do you > think?A watchdog can not avoid a task being not called. In most cases the watchdog just resets the complete system if it is not serviced fast enough (by the task(s) being watched). There is however no guarantee that the offending task will run after the reset. There may be some permanent failure that prevents it from running. You can use a watchdog in an RTOS as well, but you have to make sure your task will run within the required watchdog service interval. What do you think the 'RT' in 'RTOS' stands for? What is the difference between your 'real time' and using an RTOS? -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) It is better to have loved a short man than never to have loved a tall.
Reply by ●January 21, 20192019-01-21
On 1/21/19 7:40 AM, Robert Willy wrote:> Hi, > I was asked the question in the title some time ago. I had some real-time > embedded system experience but with RTOS. A watch-dog can avoid a task not > called in a real-time system. But in a RTOS, what is the right answer for it? > I knew task priority, a timer triggered event all can influence a task execution. > But they didn't look like the correct answer. What is the right answer do you > think? > > Best Regards, >If you question is how to make sure that every task gets the time it needs within it required time limits, in general this is impossible, as if you mis-design your system, you may end up with 110 units of work to do in 100 units of time, which is fundamentally unsolvable. Different RTOSes have different scheduling methods, mostly in a few standard technologies. If you have an RTOS with strict execution priorities, then the only thing that can keep a current task from getting the CPU to try and meet its deadlines are task with higher priorities (or there is a case where lower priority tasks might hold resources needed). If you can characterize and limit the time that those higher priority tasks might consume, then you can come up with some gaurentees for execution of that task. Another method sets priorities based on how close the task is to its deadline, which as long as no other tasks have fallen behind their deadline (if past deadline is given priority) should get some time as the deadline approaches. You can also create ad-hoc solutions where some high priority task periodically adjusts priorities to try and make sure a given task gets the time it needs (normally an indication that something wasn't designed right the first time).
Reply by ●January 21, 20192019-01-21
Am 21.01.2019 um 13:40 schrieb Robert Willy:> A watch-dog can avoid a task not called in a real-time system.No, it really can't. It can only _react_ to a supervised task not having been called in time. But it cannot keep that from happening in the first place, i.e. it cannot "avoid" it. Nor can it usually guarantee that a bite of the dog will actually resolve the issue.> But in a RTOS, what is the right answer for it?Quite probably the same, because there is not really a difference between "real-time system" and "RTOS". Any sufficiently badly designed application can fail to perform some task before its allotted deadline. If that renders the performance of said application unacceptable, that means the buzz-word "real-time" has been applied to it correctly --- quite often it isn't. Nor is there such a thing as "the" right answer to the question "what should I do if this happened to me?" Like for all somewhat interesting questions, the only universally applicable answer is "It depends." In a perfect world the answer might be "Just make sure your system has sufficient resources in all areas that this simply cannot happen, and then some" --- but in most corners of this here reality bean-counters will tell you, in excruciating detail if you insist, why that answer is completely not incorrect, but actually blasphemous.
Reply by ●January 22, 20192019-01-22
On Mon, 21 Jan 2019 13:05:15 -0500, Richard Damon <Richard@Damon-Family.org> wrote:>On 1/21/19 7:40 AM, Robert Willy wrote: >> Hi, >> I was asked the question in the title some time ago. I had some real-time >> embedded system experience but with RTOS. A watch-dog can avoid a task not >> called in a real-time system. But in a RTOS, what is the right answer for it? >> I knew task priority, a timer triggered event all can influence a task execution. >> But they didn't look like the correct answer. What is the right answer do you >> think? >> >> Best Regards, >> > >If you question is how to make sure that every task gets the time it >needs within it required time limits, in general this is impossible, as >if you mis-design your system, you may end up with 110 units of work to >do in 100 units of time, which is fundamentally unsolvable. > >Different RTOSes have different scheduling methods, mostly in a few >standard technologies. > >If you have an RTOS with strict execution priorities, then the only >thing that can keep a current task from getting the CPU to try and meet >its deadlines are task with higher priorities (or there is a case where >lower priority tasks might hold resources needed). If you can >characterize and limit the time that those higher priority tasks might >consume, then you can come up with some gaurentees for execution of that >task.There are some simple rules of thumb that I have used successfully for decades. 1.) Analyze your task and find out which priorities can be _lowered_ without harming the total system performance. In this way, the few higher priority tasks should have plenty of execution time, without constantly fighting with low priority tasks for CPU time. 2.) The higher the priority, the shorter the execution time should be. Treat the highest priority tasks like "pseudo interrupts". Move any non-hard-RT functions into the null task, which can consume all CPU time after all high priority tasks have ben served. 3.) If some task takes too long to execute for its priority, consider splitting the functionality into two task, less time critical things to a lower priority task (or even null task) and the essential things into a small high priority task. 4.) Avoid uncontrolled resource locking. If some resource needs to be locked, use a dedicated high priority transaction handler task with well defined execution time to handle the transaction from beginning to end.> >Another method sets priorities based on how close the task is to its >deadline, which as long as no other tasks have fallen behind their >deadline (if past deadline is given priority) should get some time as >the deadline approaches. > >You can also create ad-hoc solutions where some high priority task >periodically adjusts priorities to try and make sure a given task gets >the time it needs (normally an indication that something wasn't designed >right the first time).
Reply by ●January 22, 20192019-01-22
On 21/01/2019 13:40, Robert Willy wrote:> Hi, > I was asked the question in the title some time ago. I had some real-time > embedded system experience but with RTOS. A watch-dog can avoid a task not > called in a real-time system. But in a RTOS, what is the right answer for it?I have heard the use of watchdogs as being like hitting a dead man on the head with a hammer in the hope that it will wake him. Watchdogs with reset can be useful if you have hardware issues - dodgy power supplies, radiation, or something that has a risk of giving an unexpected one-off glitch that stops the system working properly. If the problem is in software, however, it will just lead to the same situation again and again. For software issues, watchdogs are more about helping you identify and debug problems - they don't fix anything, they just let you know you have a problem. But in no sense does a watchdog /avoid/ a task not doing its job. At best, it can help you see that the task has not succeeded. There are usually better ways (RTOS or not) to do this, if you think it is necessary. The only way to avoid a task not being called is to be sure that you design the system properly.
Reply by ●January 22, 20192019-01-22
On Mon, 21 Jan 2019 04:40:38 -0800 (PST), Robert Willy <rxjwg98@gmail.com> wrote:>Hi, >I was asked the question in the title some time ago. I had some real-time >embedded system experience but with RTOS. A watch-dog can avoid a task not >called in a real-time system. But in a RTOS, what is the right answer for it? >I knew task priority, a timer triggered event all can influence a task execution. >But they didn't look like the correct answer. What is the right answer do you >think? > >Best Regards,The "RT" in RTOS stands for "real time". A watchdog generally tells you that some task either was not run, or was not run on time. It knows this because the task resets the watchdog's timer as part of its operation. If the watchdog expires, you know that the task, for whatever reason, failed to reset it. So the task running properly avoids the watchdog expiring. From another point of view: a watchdog could be designed to start a particular task when it expires. In this case execution of that task could be avoided by something else continually resetting the watchdog. If neither of these answer your question, then I don't understand what you're asking. George
Reply by ●January 22, 20192019-01-22
Am 22.01.2019 um 09:19 schrieb David Brown:> On 21/01/2019 13:40, Robert Willy wrote: >> Hi, >> I was asked the question in the title some time ago. I had some real-time >> embedded system experience but with RTOS. A watch-dog can avoid a task not >> called in a real-time system. But in a RTOS, what is the right answer for it? > > I have heard the use of watchdogs as being like hitting a dead man on > the head with a hammer in the hope that it will wake him.That's overstating it teeny little bit. ;-) It's more like hitting a newly dead heart with a hefty jolt of electricity to possibly make it restart --- a procedure that is quite definitely not recommended to be used on a non-dead one. And just like the bite of a watchdog, that sometimes actually does work.> If the problem is in software, however, it will just lead to the > same situation again and again.That's by no means certain. It all depends on how it happened that the software got itself stuck in a situation that didn't occur during testing (or the software would never have been released into the wild, right?) But somehow, right now it did. If a e.g. once-in-a-blue-moon "forbidden" excession of design limitations on some input was the reason, a watch-dog reset cures the problem until the next event of that kind --- i.e. possibly forever.
Reply by ●January 22, 20192019-01-22
On Tuesday, January 22, 2019 at 4:10:33 PM UTC-5, Hans-Bernhard Bröker wrote:> Am 22.01.2019 um 09:19 schrieb David Brown: > > I have heard the use of watchdogs as being like hitting a dead man on > > the head with a hammer in the hope that it will wake him. > > That's overstating it teeny little bit. ;-)I just returned from a presentation by Don Eyles about the Apollo missions. He discussed how the watchdog kept resetting the LEM computer during the Apollo 11 descent. Even more scary was the Astronaut-hand-applied patch during Apollo 14 to circumvent an intermittent short in the LEM "Abort" button. Don't get too concerned, just press on... Looking forward to reading his memoir (had to buy a copy)! https://www.amazon.com/Sunburst-Luminary-Apollo-Don-Eyles/dp/0986385905 See ya, Dave PS: Now, how's THAT for thread drift?
