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

[@mohamedhassanin6054]

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]

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

[@AlonchBreak]

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

[@Clark-Mills]

Great work, really appreciate the quality of your work.

[@ShawnHymel]

Thanks!

[@josephlai7737]

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]

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]

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]

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

[@qcsupport2594]

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!

[@AgainPsychoX]

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

[@TS-kg4lf]

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

[@gaotengwang]

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

[@andrewabilevich7370]

so touching for an excellent video

[@zee-lab-electronics]

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

[@ShawnHymel]

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

[@ethanzheng4673]

Great explanation!

[@chrisalfred5567]

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.

[@sankalpnegi7626]

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 !

[@Kravch96]

He is too perfect

[@digikey]

We think so too. There's a conspiracy that he's a robot. ;)

[@reginaldsykes]

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]

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

[@mikoajchyczynski5707]

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.

[@narsino]

thank you!

[@gacherumburu9958]

👍

[@tosemusername]

@Digi-Key I don't get the 4:3-ish window size of the arduino IDE in the videos.

[@YaroslaffFedin]

Looks like the author puts two code editors side by side to copy code from one another, so he only records one of the windows. Still not great.

[@nilton61]

Do not use delays of other blocking code

[@awesomdev]

Whats' the meaning of sw?

[@devkumar9889]

PCP info was not clear and wrong I guess

[@tinashetanyaradzwamabika2422]

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]

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.

[@intheshell35ify]

What are you talking about?!?! Bunch of cs dropouts.