 Another method of synchronization of the tasks is a direct to task notification. This feature was implemented from the free RTOS release in the version 8.2 and in CMC's OS it's covered by a little bit lower features called signals. So the task notification is much faster than other synchronization methods. And it allows you to send the notification a binary value to the tasks defined by a task ID. In terms of CMC's OS API the feature is defined as a signals and you can see that we can send a signal to the task with the OS signal set with a thread ID where we send it to and the binary combination of signals. And when we wait for the signals we can use the function OS signal wait where we expect some signals and the amount of milliseconds. In the native API these signals can be masked. So you can wait for a specific mask of signals or specific bits and you can define if there should be a logical or logical end between the signals. Which means that the signals have a sticky characteristics. If you set a signal on bit number 0 it will set bit number 0 to 1. If you send a signal on bit number 3 it will set the bit number 3 inside this mechanism. But if you wait for a signal with a combined value of bit number 3 and bit number 0 which is 9 value 9 if in the native API you set I'm waiting for number 9 with a logical function or any of the bits you wait for will release the message. But if you wait with a logical function and the complete number 9 must be present in the signals to release the task. CMC's API allows only the function or so any of the signals defined in the mask will release the task from a blocking state. So remember signals are faster mechanism and they allow you to give a specific task directly a signal please now go on. We can for example define a button press as a signal with a value number 1 and when we enable the button interrupt on XTI we can put in the callback the signal to this specific task and if in this start task I'm waiting for the button press forever if I press the button the interrupt will give me a signal the task will be awakened and then it will proceed with whatever I want it to. So this way you have a very efficient synchronization between either tasks or interrupts and the tasks themselves. It's similar to semaphores but it's faster because for semaphores you have got the task in a blocked list with an object which is the semaphore it is waiting for. So when you release a semaphore it's quite a complicated thing because you need to look into the object you need to lock it you need to insert the semaphore or the token into the semaphore and then you have to parse the list of blocked tasks and check if which task is waiting for the semaphore and then if it's waiting for this specific object you have to put it into the ready state and then you have to do the context switch and possibly you get to this task. This operation on further objects while the signal sending is just I have got a specific task if it's blocked let's set an internal variable inside and if it's waiting for it let's release it. So it doesn't need to interfere with any other object like a semaphore because the signal is internal to the specific task. The API for the signals is OS signal set to OR the new value with the existing signal. We can okay this is not implemented here to clear the signal and we can wait for the signal in a blocked way in the task.