 So, what is a mutex? Mutex is a token. Have you ever run in a series of, let's say, runs where you have got different people who pass the token? So, if you don't have the token, you don't run. If you have the token, you can run. The mutex object is effectively a token. It's opposite to the binary semaphore because when you define it, it is present. It always has a number one and it works so that it guards some shared resource. It can be access to the UART. You can imagine if two tasks write to the UART at the same time, it can be MS because here it will work. Here it starts putting the characters in between because as you switch between, for example, the scheduler switches between the tasks, the characters can be sent from the two tasks in parallel. So, physically, they will interchange on the UART and instead of hello world message, you get H1, E2, so a mixed message. So, UART in such case would be a shared critical resource. So, we will create a mutex that will guard the UART. So, we can call it, for example, a UART mutex. And it will define an object in the heap. And now, if I have got task one and I want to use the UART, first I have to have the token to use the UART. So, I will try to acquire the mutex and if I am able to get it, I will use the UART. If the mutex is not present, I will get blocked. I can't continue, I can't use this UART. So, only when the task that got the mutex finishes, it must return the mutex back. So, it gives the token back and other task waiting for the UART can take the token now. It will use the UART serially after the task one finished and then again it must return the token. So, by the deal that every task that uses the UART will wait for the mutex. You are able to synchronize the tasks and you don't allow the tasks to run if they don't have the token. So, it's like with the car in Avis, when you come to the parking lot at the beginning there is one car, you can take it. If you return it back, somebody else can take it as well. But if you don't return it back, it's yours for the time being. That's exactly how you would work with mutex guarding the UART. If you take the mutex, UART is yours. If you return it back, somebody else can take it and use the UART. Until the time the other tasks are blocked and have to wait for the mutex. The mutexes are very similar to the semaphores where it changes, it is the initialization. Because during initialization the mutex is put inside, so it's existing at the beginning. And there is additionally one thing very useful. If you have two tasks where both of them wait for the same mutex or, for example, the lower priority task owns the mutex and the higher priority task waits for it. You see that the high priority task would get the priority if it would be running. However, the lower priority task must get the running state because it will release the mutex for high priority task. If this wouldn't happen, if this wouldn't be implemented, a priority inversion would occur and you would be deadlocking the execution. So the free RTOS is able to prevent the priority inversion by giving the lower priority task a higher priority if a higher priority task is waiting for its resource. So this mechanism is called priority inheritance and it's managed automatically by the free RTOS. So the effect is a temporary raise of the priority for lower priority task. The trouble of using several different synchronization objects together is called deadlock. It can happen that two tasks require two different resources. And at one point one task was able to acquire one resource, the other task was able to acquire the second resource and they both wait for the other resource. At this moment there is a really bad luck because no one of these two tasks is able to acquire the other resource and give up its own. So at that situation you completely lock these two tasks and they cannot continue. So when you design your application you should avoid the deadlock and you should think about it in a design time so that you never wait for the two resources in a crossed way. And now let's look at the mutexes. We have got a mutex present at the beginning and we use it to guard a shared resource. So if the task one uses OS mutex wait, the mutex can be transferred to the task one and the task one will use the resource. If the task one is finished it can give back the mutex and the resource will be released. The next task, task two can then because it was waiting for the same mutex can obtain it, then it's awakened and when it receives the mutex it can use the shared resource. Then it will return the mutex so it comes back and you have got a nice ping pong where no task can interfere with the shared resource if it complies with the mutex guarding. For mutexes you have got a specific API so using the OS mutex create you can create an instance. You can wait for the mutex again with a timeout and when you are finished with the job and you own the mutex you can release it. There is as well a possibility for a recursive mutex and the recursive one can be used within one single task to get the mutex periodically but return it only once. So it's not counting but it allows you to get the mutex several times in the same task so it gets a little bit easier for the code flow. I can list the APIs and the appropriate usage of the native APIs. You can see that inside it uses the semaphores so same mechanism but the semaphore is defined with length one and it's put at the beginning inside.