Using Ozone, load Chapter8_mutexExample.elf and run the MCU. Here's what to expect when looking at the board:

• You'll see double blinking green and blue LEDs. The LED blinks of each color will not overlap one another, thanks to the mutex.
• There will only be a few red LED blips every once in a while. This reduction is caused by TaskB not being allowed to take priority over TaskC (and blocking TaskA). This is a  lot better than before, but why are we still seeing red occasionally?

By opening SystemView, we'll see something like the following:

Looking through the terminal messages, you'll notice that TaskA – the highest-priority task in the system – has never missed a mutex. This is what we expect since it has priority over everything else in the system. Why does TaskC occasionally miss a mutex (causing a red LED)?

1. TaskC attempts to take the mutex, but it is being held by TaskA.
2. TaskA returns the mutex, but it is immediately taken again. This is caused by a variable amount of delay in TaskA between calls to the mutex. When there is no delay, TaskC isn't allowed to run between when TaskA returns the mutex and attempts to take it again. This is reasonable since TaskA has a higher priority (though this might not be desirable in your system).
3. TaskC times out, waiting for the mutex.

So, we've improved our condition. TaskA, which is the highest-priority task, isn't missing any mutexes any more. But what are some best practices to follow when using mutexes? Read on to find out.