Introduction to RTOS Part 11 - Priority Inversion | Digi-Key Electronics
HTML-код
- Опубликовано: 29 сен 2024
- Priority inversion is a nasty concurrency bug that occurs when a low priority thread prevents a high priority thread from running. In a sense, the priority structure has been “inverted,” as the low priority thread gets to run first.
The code for the challenge, which starts with unbounded priority inversion, can be found here: github.com/Sha...
The solution to the challenge can be found here: www.digikey.co...
Code for this video series (including demonstrations, challenges, and solutions) can be found here: github.com/Sha...
Bounded priority inversion happens in the simple case where a high priority task takes a lock (e.g. mutex or semaphore) and prevents a high priority task from running, as the high priority task is blocked waiting for the same lock. We consider this “bounded” because the blocking is bounded by the length of time the low priority task is executing inside the critical section (prior to returning the lock).
Preventing bounded priority inversion requires careful thinking about how the threads interact and either limiting or avoiding critical sections. One possible solution is to create a task (or thread) that manages a shared resource. All other threads must use queues (or other synchronization techniques) to send and receive data from this task.
Unbounded priority inversion occurs when a medium priority task preempts a low priority task that’s holding a lock needed by a high priority task. It’s “unbounded” because the amount of time that the high priority task is blocked is dependent on the time the medium task runs without yielding to the low priority task (which needs to release the lock).
We can prevent unbounded priority inversion through the use of the priority ceiling protocol or priority inheritance, which we cover in the video. Both techniques require that the priorities of tasks can be dynamically changed at runtime. Note that both techniques do not prevent bounded priority inversion.
Product Links:
www.digikey.co...
Related Videos:
Introduction to RTOS Part 1 - What is a Real-Time Operating System (RTOS)? - • Introduction to RTOS P...
Introduction to RTOS Part 2 - Getting Started with FreeRTOS - • Introduction to RTOS P...
Introduction to RTOS Part 3 - Task Scheduling - • Introduction to RTOS P...
Introduction to RTOS Part 4 - Memory Management - • Introduction to RTOS P...
Introduction to RTOS Part 5 - Queue - • Introduction to RTOS P...
Introduction to RTOS Part 6 - Mutex - • Introduction to RTOS P...
Introduction to RTOS Part 7 - • Introduction to RTOS P...
Introduction to RTOS Part 8 - • Introduction to RTOS P...
Introduction to RTOS Part 9 - • Introduction to RTOS P...
Introduction to RTOS Part 10 - • Introduction to RTOS P...
Introduction to RTOS Part 11 - • Introduction to RTOS P...
Introduction to RTOS Part 12 - • Introduction to RTOS P...
Related Project Links:
www.digikey.co...
Related Articles:
www.digikey.co...
Learn more:
Maker.io - www.digikey.co...
Digi-Key’s Blog - TheCircuit www.digikey.co...
Connect with Digi-Key on Facebook / digikey.electronics
And follow us on Twitter / digikey
![DDG & G Herbo - Nosey [Official Video]](http://i.ytimg.com/vi/I9Ra0Zc2NlQ/mqdefault.jpg)
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
RTOS is perfect for my projects and this video series helps a lot
You did a great job at keeping sessions interesting with real-life examples!
In part 11, the subtitle are wrong. The source language is English, but it was set to Vietnamese by mistake.
What are you talking about?!?! Bunch of cs dropouts.
Great work, really appreciate the quality of your work.
Thanks!
Awesome Shawn.
It would be great if you start tinyML video series (on esp32-cam) , 🤗.
Is it possible? 😊.
I've got a few TinyML videos and a course out there, but nothing on vision. Good to know there's interest!
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.
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()).
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.
Happy hacking! ;) I'm glad to hear that you're finding them helpful!
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!
One way to check that is an integration test where you call all tasks to see if the hierarchy is respected
I love the videos, interesting topic, and so good quality
PCP info was not clear and wrong I guess
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.
I totally think the same thing! Have you been able to understand yet?
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.
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.
Do not use delays of other blocking code
so touching for an excellent video
👍
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 !
Whats' the meaning of sw?
@Digi-Key I don't get the 4:3-ish window size of the arduino IDE in the videos.
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.
Great explanation!
thank you!
He is too perfect
We think so too. There's a conspiracy that he's a robot. ;)
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
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.