 Let's look for a while about resource management within 3R ties. There are few mechanisms for resource management implemented within 3R ties. The most important one is the critical section. It is widely used across operating system functions, as all operations done on task semaphore, skew, smotex, software timers needs to be done within the critical sections. Why? To be sure that there is always single place where we modify state of operating system components, otherwise it could create unstability of the operating system and its crash. We are starting critical section by macro task enter critical and leaving it by task exit critical. It will be described more in details on next slides. Next technique for resource management is the possibility to suspend the scheduler. It allows the embedded system to perform some critical operations without any intervention from the operating system. We can suspend the scheduler by calling vtask suspend all function and unblock it by calling x task resume all function. Important point here is that it is not allowed to call any operating system API function when the scheduler is suspended. We can see more details, more functions which are available to suspend and resume the scheduler within the scheduler section in this training. Last technique is a gatekeeper task implementation. We call it a dedicated task to manage some shared resources like usart or display interface to be sure there is no access conflict nor deadlock which could happen. We will describe it more in details in a while. Last technique we will mention here is usage of motexes. Motex as we will see in dedicated section is a kind of binary semaphore with some more intelligence and memory inside. The price of it is that it increases a memory usage by each of the tasks by extending tcb so task control block size. Critical sections. Critical section mechanism allows us to block all the interrupts during sensitive or atomic operation execution of an operating system in particular. The blocking of the interrupts it is valid only for the interrupts which are using operating system functions. So till the level specified by the configuration config library marks syscall interrupt priority. All interrupts with higher priority than this one would be not blocked. So our hardware which is important for our application will still be fully operational. Its interrupts would be executed, would be not blocked. The blocking point would be only for operating system and its components. And all interrupts which are cooperating with the operating system functions. To enter into the critical section we are using the macro port enter critical to exit from it port exit critical is used. As you can see from the picture below when the port enter critical what we are doing we are configuring base pre system register with the value of config library marks syscall interrupt priority to block all the interrupts related to the operating system. Then we can perform any operation which is touching which is modifying hues tasks semaphores and after the sensitive code execution we can restore the base pre so the masking register to the default value which is zero. So in this case all the interrupts are unlocked and unblocked in this case. Gatekeeper task is a concept which needs to be implemented by the designer. There is no dedicated functions nor structures which would support it in current free air toys implementation. The idea behind this concept is quite simple. Gatekeeper is a task being the only allowed to access certain resources like peripherals or memory buffers. Other tasks can access those resources indirectly by calling a gatekeeper services. This task should spend most of its time in a blocked state waiting for the access requests to the guarded resources and it is up to the designer to set the priority and the name of this task. It is providing clean method to implement mutual exclusion without any risk of priority inversion of deadlock. Thank you for watching this video.