Introduction to RTOS Part 11 - Priority Inversion

Introduction to RTOS Part 11 - Priority Inversion | Digi-Key Electronics

Рет қаралды 59,709

Күн бұрын

Пікірлер: 36

@mohamedhassanin6054 3 жыл бұрын

0:00 Mars Rover Pathfinder 1:14 bounded priority inversion 2:47 bound task 3:39 Mars rover bounded priority inversion 6:03 bounded priority inversion demo 7:59 priority ceiling protocol 9:49 priority inheritance 10:56 priority inheritance demo with FreeRTOS mutex 11:20 challenge

@tehmudjinkhan2207 3 жыл бұрын

RTOS is perfect for my projects and this video series helps a lot

@AlonchBreak 3 жыл бұрын

You did a great job at keeping sessions interesting with real-life examples!

@Clark-Mills 3 жыл бұрын

Great work, really appreciate the quality of your work.

@ShawnHymel 3 жыл бұрын

Thanks!

@gaotengwang 4 ай бұрын

In part 11, the subtitle are wrong. The source language is English, but it was set to Vietnamese by mistake.

@josephlai7737 3 жыл бұрын

It seems to me it is better to disable preemption or interrupt altogether for any critical section, for two reasons. One: critical sections are short, they are non-blocking, so the protected resource will be available for the task with higher priority (be it the task that wants to preempt the current task, or an interrupt service routine) very soon. Two: this way, no priority inversion will happen, including the bounded type. Of course, the lower priority task should yield to higher priority task immediately after it releases the resource. What are the reasons for not disabling preemption/interrupt? # Edit: As the video continues, I realized what I was talking about are called critical markers and do exactly that.

@ShawnHymel 3 жыл бұрын

Good question! Disabling preemption and interrupts during critical sections does make it much easier to prevent priority inversion. You generally want preemption when you have high priority tasks that should stop another task from running to perform some task immediately (I.e it cannot wait for the low priority task to explicitly yield the processor with a vTaskDelay()).

@MrWATCHthisWAY 3 жыл бұрын

Darn Shawn no Happy Hacking at the end of your lesson this time? These lessons are all coming together for me now as you build on each segment. Thank you and DigiKey for these lessons because it helps out tremendously in understanding the of architecture & function of the programming.

@ShawnHymel 3 жыл бұрын

Happy hacking! ;) I'm glad to hear that you're finding them helpful!

@qcsupport2594 3 жыл бұрын

Your challenge for Part 11 is to build a rover, land it on Mars, detect any priority inversions, and fix them from Earth. Happy Hacking!

@reginaldsykes 2 жыл бұрын

I am somewhat confused by the explanation of what is happening to create the "priority inversion" issue that affected the Mars rover. I listened to the explanation several times but I feel that some part of the explanation is either missing or I am misunderstanding. From 4:21 to 4:56 ... you stated "Every now and then, the medium priority task would run while the low priority task was in the critical section. As you can see, task 'H' is still blocked and it will remain blocked so long as task 'L' has the mutex. And, task 'L' won't run to release the mutex as long as task 'M' is running." Here is where I am confused. If task 'L' has the mutex, and task 'H' is being blocked, that should mean that no task can work in the critical section until task 'L' releases the mutex. You stated that "task 'L' won't run to release the mutex as long as task 'M' is running. This is confusing to me. Can you explain why task 'M' is a factor if it doesn't have the mutex and is not holding a resource that task 'L' needs in order to complete task 'L's task? Why wouldn't task 'L' just complete its task, release the mutex, and task 'H' and task 'M' are free to take the mutex if they need to run in this critical section? I don't understand what task 'M' has to do with this if task 'M' is not using this critical section. I'm sure I missed something here. Please explain.

@seferideveloper6933 2 жыл бұрын

I totally think the same thing! Have you been able to understand yet?

@mikoajchyczynski5707 2 жыл бұрын

What I understood: because task M has higher priority than task L, task L will be preempted and task M will run. Because taks M does not use use critical section it will not be stopped by it (like task H was stopped) and it will not let task L finish with critical section because it doesn't need the critical section and doesn't care about it. Task M can run for a long of time without interrupts (because is higher prio than L and because task H is not gonna to preempt it because it is blocked by critical section) and all of that time task L is holding critical section that task H wants to use. So finally medium priority task runs freely and high priority task is blocked (that's the inversion of priorities). For the Mars rover task M run and blocked tasks L & H for enough time to trigger watchdog.

@chrisalfred5567 2 жыл бұрын

At 3:16 You say that queue 2 can be replaced by "a global variable that Task A and B have read-only access to". Surely that will cause race conditions as The "Service Task" can not know when Task A or Task B are reading the variable to coordinate the write to the global variable; and conversely Task A and Task B can not know when the Service Task is about to write to the global variable to coordinate their reads.

@AgainPsychoX 3 жыл бұрын

I love the videos, interesting topic, and so good quality

@TS-kg4lf 3 жыл бұрын

One way to check that is an integration test where you call all tasks to see if the hierarchy is respected

@sankalpnegi7626 3 жыл бұрын

Hey, great job on the content, keep it up ! However, I disagree on the concept "Bounded Priority Inversion", as I think its not a "Priority Inversion", at all ! As we see in the video 2:17, in "Bounded Priority Inversion", the higher priority task is waiting on a lower priority task, but, due to a resource contention, and NOT because of any priority specific scheduling decision making. We need to understand that priority is NOT always the sole metric of scheduling ! As we see in this case, the priority metric is shadowed by resource contention logic. Hence, by design, its completely intentional, and not an anomaly. The priority scheduling was never broken here (its just that it was not significant enough to be considered in this case). So, this may be termed as a type of "Priority Inversion", but only in a poetic sense, as it has no technical backing ! Feel free to correct me, Thanks !

@andrewabilevich7370 2 жыл бұрын

so touching for an excellent video

@ethanzheng4673 2 жыл бұрын

Great explanation!

@zee-lab-electronics 3 жыл бұрын

Awesome Shawn. It would be great if you start tinyML video series (on esp32-cam) , 🤗. Is it possible? 😊.

@ShawnHymel 3 жыл бұрын

I've got a few TinyML videos and a course out there, but nothing on vision. Good to know there's interest!

@antoni2nguyen 24 күн бұрын

In the other words: NASA and JPL should use FreeRTOS to save tones of people money :D

@tinashetanyaradzwamabika2422 2 жыл бұрын

thank you for the awesome content. referring to diagram on 2:44 , what if we have another task that keep tracks of the task holding the mutex so that when another task of high priority interrupts, it will call the task holding the mutex to release it so that it proceeds to do its work

@vidu7479 5 ай бұрын

if you already need a mutex to protect the shared resource, you wont want other tasks to mess up with it. Let's have an analogy .If you go pee pee and other guy wants you go out for his poop poop, at least you want to finish your stuff first.