|
|
| Line 1: |
Line 1: |
| | [[category: Free RTOS with Arduino]] | | [[category: Free RTOS with Arduino]] |
| − | In this tutorial, we will be discussing a Semaphore and its types ie. Binary, Mutex, Counting.<br> | + | In earlier tutorials, we saw how to create, delete, suspend and resume the tasks.<br> |
| − | Later we will see each semaphore in detail with its pros and cons.
| + | In this tutorial, we will see how to read the Task info(state, Stack size, priority.<br> |
| − | Also, we will be looking into priority inversion and priority inheritance.<br><br>
| + | |
| | | | |
| − | ==Teminologies== | + | =API Details= |
| − | #<b>LPT:</b> Low Priority Task
| + | Here we will discuss some of the most frequently used APIs related to tasks. |
| − | #<b>MPT:</b> Medium Priority Task
| + | |
| − | #<b>HPT:</b> High Priority Task
| + | |
| | | | |
| | + | <b>xTaskCreate()</b>: This interface is used to create a new Task, if the task is successfully created then it returns pdPass(1) or else errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY(-1). Check [http://www.freertos.org/a00125.html this link] for more details.<br> |
| | | | |
| − | =What is a Semaphore?=
| + | <b>vTaskDelay()</b>: This function is used to delay/block the task for specified delay time(ticks). INCLUDE_vTaskDelay needs to be set to 1 in FreeRtosConfig.h file for using this function. Check [http://www.freertos.org/a00127.html this link] for more details.<br> |
| − | Semaphore is a technique for synchronizing two/more task competing for the same resources. When a task wants to use a resource, it requests for the semaphore and will be allocated if the semaphore is available. If the semaphore is not available then the requesting task will go to blocked state till the semaphore becomes free.
| + | |
| | | | |
| − | Consider a situation where there are two persons who want to share a bike.
| + | <b>vTaskSuspend():</b> This function is used to Suspend a task, the suspended remains in the same state util it is resumed.<br> |
| − | At one time only one person can use the bike. The one who has the bike key will get the chance to use it. And when this person gives the key to the 2nd person, then the 2nd person can use the bike.
| + | For this, we need to pass the handle of the tasks that needs to be suspended. Passing NULL will suspend own task. Check [http://www.freertos.org/a00130.html this link] for more details. |
| | | | |
| − | Semaphore is just like this <b>Key</b> and the bike is the shared resource.
| + | <b>vTaskResume():</b> This function is used to resume a suspended task. If the Resumed task has higher priority than the running task then it will preempt the running task or else stays in ready state<br> |
| − | Whenever a task wants access to the shared resource, it must acquire the semaphore first.
| + | For this, we need to pass the handle of the task to be resumed. Check [http://www.freertos.org/a00131.html this link] for more details. |
| − | The task should release the semaphore after it is done with the shared resource.
| + | |
| − | Until this time all other tasks have to wait if they need access to shared resource as semaphore is not available.
| + | <b>vTaskList():</b> This function is used to read the task details(name, state, priority, num). We need to pass a string pointer(buffer) to which it copies the above task details. The buffer size should be minimum 40 bytes per task. Check [http://www.freertos.org/a00021.html#vTaskList this link] for more details. |
| − | Even if the task trying to acquire the semaphore is of higher priority than the task acquiring the semaphore,
| + | |
| − | it will be in the wait state until the semaphore is released by the lower priority task.
| + | |
| | <br><br> | | <br><br> |
| | | | |
| − | =Types of Semaphores= | + | =Example1= |
| − | There are 3-types of semaphores namely Binary, Counting and Mutex semaphore.
| + | In this example, we will be creating 3-tasks which run for some time and enter the blocked state allowing other tasks to run. We will include INT0 falling edge interrupt to read and display the current task list with all the task info. Every time interrupt is generated it will take the snapshot of tasks(name, state, priority, num) and sends on Serial port. |
| − | *<b>Binary Semaphore</b>: Binary semaphore is used when there is only one shared resource.
| + | <html><script src="https://gist.github.com/SaheblalBagwan/c696f165daba3e2826cd3b9ebf33785f.js"></script></html> |
| − | Binary semaphore exists in two states ie.Acquired(Take), Released(Give).
| + | |
| − | Binary semaphores have no ownership and can be released by any task or ISR regardless of who performed the last take operation. Because of this binary semaphores are often used to synchronize tasks with external events implemented as ISRs, for example waiting for a packet from a network or waiting for a button is pressed.
| + | |
| | | | |
| − | Because there is no ownership concept a binary semaphore object can be created to be either in the “taken” or “not taken” state initially.
| + | =Output1= |
| | + | [[FILE:VTaskList().png]] |
| | + | <br> |
| | + | All the tasks will be running for some time and enter the blocked state allowing other tasks to run. Task3 suspends and resumes the Task1 alternatively. |
| | + | Whenever INT0 interrupt is generated, ISR will take the snapshot of all the task and sends it on the serial port. |
| | | | |
| − | Cons:
| |
| − | #Priority Inversion : HPT needs to wait for the LPT as LPT is holding the resource required for HPT. In between if MPT task comes then LPT will be in blocked state thereby delaying HPT.
| |
| − | #Does not support recursion : If a task tries to take the semaphore twice then it gets blocked and will not come out of that state till someone releases that semaphore.
| |
| − | #No ownership : Anyone can release or delete the semaphore because of which the dependent tasks will always be in the blocked state.
| |
| | | | |
| − | *<b>Counting Semaphore</b>: To handle more than one shared resource of the same type, counting semaphore is used. Counting semaphore will be initialized with the count(N) and it will allocate the resource as long as count becomes zero after which the requesting task will enter blocked state.
| |
| | | | |
| − | *<b>Mutex Semaphore</b>: Mutex is very much similar to binary semaphore and takes care of priority inversion, ownership, and recursion.
| + | =Downloads= |
| − | | + | Download the complete project and libraries from [https://github.com/ExploreEmbedded/Arduino_FreeRTOS/archive/master.zip here].<br><br> |
| − | | + | |
| − | =Priority Inversion= | + | |
| − | This is a scenario where the HPT waits for the LPT as it is using the resource required by HPT.<br>
| + | |
| − | Let's see 3 different scenarios of priority inversion depending on the amount of time HPT waits for the lower priority tasks.
| + | |
| − | *<b>Normal Priority Inversion:</b> Here an HPT tasks waits for the LPT tasks as it is holding the resource(semaphore).
| + | |
| − | #LPT starts running and acquires the semaphore.
| + | |
| − | #Now HPT is created and it preempts LPT and starts running. It makes the request to acquire the semaphore. Since the semaphore is already with LPT, HPT goes to blocked state.
| + | |
| − | #LPT starts executing again and releases the semaphore.
| + | |
| − | #Immediately the HPT comes out of the blocked state and starts executing.
| + | |
| − | #It releases the semaphore and runs for some time and deletes itself.
| + | |
| − | #Now control goes back to LPT which completes its job and deletes itself.
| + | |
| − | #Finally the scheduler is left out with the idle task and it keeps running.
| + | |
| − | | + | |
| − | In this scenario, the HPT task waits for LPT from 2-4 which is the priority inversion period.
| + | |
| − | [[File:PriorityInversion.png]] <br><br> | + | |
| − | | + | |
| − | *<b>Extended Priority Inversion:</b>Here an HPT tasks waits for the LPT tasks as it is holding the resource(semaphore). Further, the LPT waits for the event/data to be received and the CPU executes the IDLE tasks. This makes the HPT wait for more time.
| + | |
| − | #LPT starts running and acquires the semaphore.
| + | |
| − | #Now HPT is created and it preempts LPT and starts running. It makes the request to acquire the semaphore. Since the semaphore is already with LPT, HPT goes to blocked state.
| + | |
| − | #LPT starts executing again and waits for an event(packet to be received).
| + | |
| − | #Now the Idle task starts running. Now the HPT is starved because of LPT and Idle task.
| + | |
| − | #LPT comes out of blocked state as the event(wait time/packet is received) has occurred. Now it releases the semaphore.
| + | |
| − | #Immediately the HPT comes out of the blocked state and starts executing. It releases the semaphore and runs for some time and deletes itself.
| + | |
| − | #Now control goes back to LPT which completes its job and deletes itself.
| + | |
| − | #Finally the scheduler is left out with the idle task and it keeps running.
| + | |
| − | | + | |
| − | In this scenario, the HPT task waits for LPT and Idle task from 2-5 which is the extended priority inversion period.
| + | |
| − | [[File:ExtendedPriorityInversion.png]]<br><br>
| + | |
| − | | + | |
| − | | + | |
| − | *<b>Worst Case Priority Inversion:</b>Here an HPT tasks waits for the LPT tasks as it is holding the resource(semaphore). In between an MPT starts executing thereby blocking the LPT and HPT. This makes the HPT wait for MPT and LPT.
| + | |
| − | #LPT starts running and acquires the semaphore.
| + | |
| − | #Now HPT is created and it preempts LPT and starts running. It makes the request to acquire the semaphore. Since the semaphore is already with LPT, HPT goes to blocked state.
| + | |
| − | #LPT starts executing again and creates an MPT tasks.
| + | |
| − | #MPT preempts the LPT and starts running. At this point, the HPT is starved because of LPT and MPT. MPT completes its job and deletes itself.
| + | |
| − | #LPT comes out of blocked state and releases the semaphore.
| + | |
| − | #Immediately the HPT comes out of the blocked state and starts executing. It releases the semaphore and runs for some time and deletes itself.
| + | |
| − | #Now control goes back to LPT which completes its job and deletes itself.
| + | |
| − | #Finally the scheduler is left out with the idle task and it keeps running.
| + | |
| − | | + | |
| − | In this scenario, the HPT task waits for LPT and MPT from 2-6 which is the extended priority inversion period.
| + | |
| − | [[File:0WorstCasePriorityInversion.png]]<br><br>
| + | |
| − | | + | |
| − | =Priority Inheritance=
| + | |
| − | As discussed in the above scenarios, the HPT has to wait for the LPT and also MPT. The scenario of HPT waiting for LPT is justified. But MPT is coming in between and blocking both LPT and HPT. MPT is not at all sharing the same resources and making the HPT wait unnecessarily.
| + | |
| − | | + | |
| − | Above problem can be resolved using the mutex semaphore. As soon as the HPT makes a request to semaphore which is allocated to an LPT then, the priority of LPT is temporarily increased to that of HPT. Once the LPT releases the semaphore, its priority will be restored. Because of this, the MPT is never allowed to interfere during the priority inversion(between LPT&HPT). MPT is only allowed to run once HPT is done with its job.
| + | |
| − | | + | |
| − | In the below scenario:
| + | |
| − | #LPT starts running and acquires the semaphore.
| + | |
| − | #Now HPT is created and it preempts LPT and starts running. It makes the request to acquire the semaphore. Since the semaphore is already with LPT, HPT goes to blocked state and LPT's priority is temporarily raised to that of HPT.
| + | |
| − | #LPT starts executing again and creates an MPT tasks. It keeps running as its priority is currently higher than MPT. It releases the semaphore and its priority is restored back to lower value.
| + | |
| − | #Immediately the HPT comes out of the blocked state and starts executing.
| + | |
| − | #HPT releases the semaphore and runs for some time and deletes itself.
| + | |
| − | #Now scheduler is left with LPT,MPT, and IDLE task. MPT starts running and deletes itself after completing its job.
| + | |
| − | #Now control goes back to LPT which completes its job and deletes itself.
| + | |
| − | #Finally the scheduler is left out with the idle task and it keeps running.
| + | |
| − | | + | |
| − | In this scenario, the HPT only waits for LPT as long as it has the semaphore. As soon as LPT releases the semaphore, HPT takes the control. Also, MPT is never allowed to interfere during the priority inversion(between LPT&HPT). MPT is only allowed to run once HPT is done with its job.
| + | |
| − | [[File:PriorityInheritance.png]]
| + | |
| − | <br><br> | + | |
| | | | |
| | Have an opinion, suggestion , question or feedback about the article let it out here! | | Have an opinion, suggestion , question or feedback about the article let it out here! |
| | {{DISQUS}} | | {{DISQUS}} |
In earlier tutorials, we saw how to create, delete, suspend and resume the tasks.
In this tutorial, we will see how to read the Task info(state, Stack size, priority.
In this example, we will be creating 3-tasks which run for some time and enter the blocked state allowing other tasks to run. We will include INT0 falling edge interrupt to read and display the current task list with all the task info. Every time interrupt is generated it will take the snapshot of tasks(name, state, priority, num) and sends on Serial port.
Have an opinion, suggestion , question or feedback about the article let it out here!
.png)