# Unexpected task behav when blocked on a queue

**URL:** <https://forums.freertos.org/t/unexpected-task-behav-when-blocked-on-a-queue/1736>\
**Category:** Kernel\
**Created:** [October 1, 2012, 3:56pm UTC](https://forums.freertos.org/t/unexpected-task-behav-when-blocked-on-a-queue/1736 "2012-10-01T15:56:59Z")\
**Posts on this page:** 3\
**Page:** 2

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [October 8, 2012, 11:51pm UTC](https://forums.freertos.org/t/unexpected-task-behav-when-blocked-on-a-queue/1736/21 "2012-10-08T23:51:12Z")

</div>

**anonymous** wrote on [Monday, October 08, 2012](https://sourceforge.net/p/freertos/discussion/382005/thread/4e59f5be/#6d75):

Just curious, what is the time (in uS) between recieving a queue message in Task 1 and releasing the data mutex in the same task?

These lines:  
&nbsp;&nbsp; //Try to get queue contents.&nbsp; If nothing is available block until something is ready.&nbsp;&nbsp;  
&nbsp; **&nbsp; if(xQueueReceive(BlockingQueue, &queueContents, WAIT\_FOREVER) == SEMAPHORE\_AVAILABLE)**  
&nbsp;&nbsp;&nbsp; {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /\*if this is the first interrupt -\> start timer\*/  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if(xSemaphoreTake(dataMutex, DO\_NOT\_WAIT) == APP\_SEMAPHORE\_AVAILABLE)  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //Do some actions  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \*\* xSemaphoreGive(dataMutex);\*\*  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }

---

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [October 9, 2012, 12:09am UTC](https://forums.freertos.org/t/unexpected-task-behav-when-blocked-on-a-queue/1736/22 "2012-10-09T00:09:36Z")

</div>

**anonymous** wrote on [Tuesday, October 09, 2012](https://sourceforge.net/p/freertos/discussion/382005/thread/4e59f5be/#7419):

So I think I might understand what could be going on here.&nbsp; I think it comes down to task switching.&nbsp; The only time FreeRTOS switches tasks is either:  
a) when a tick occurs  
b) when a FreeRTOS function is called in a task  
c) when switching out of an ISR with portEND\_SWITCHING\_ISR()

My theory on what is going on with your system is that before you go to sleep, you call a FreeRTOS function to check the queue, for cases where your pulses are \<150us, freeRTOS will see that their is a queue waiting and will service it before going to sleep.&nbsp; For \>200us, your MCU is sleeping and will be woken up by the interrupt causing an immediate task switch.&nbsp; For 200us what happens (im guessing) is you have already checked the queue, didnt see anything, your interrupt then fires, and then you continue your sleep process.&nbsp; When you wake up in that case you are now ready to process tasks 1 and 2.&nbsp;

Im still pretty sure the solution here is the portEND\_SWITCHING\_ISR macro in your ISR.

---

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [October 9, 2012, 12:13pm UTC](https://forums.freertos.org/t/unexpected-task-behav-when-blocked-on-a-queue/1736/23 "2012-10-09T12:13:44Z")

</div>

**[cmp1104](https://sourceforge.net/u/cmp1104/)** wrote on [Tuesday, October 09, 2012](https://sourceforge.net/p/freertos/discussion/382005/thread/4e59f5be/#2b3d):

To Rafleury:  
The time bewtween unblocking on the queue and giving back the mutex is ~20 - 30 us.&nbsp; I know that my timing overhead for taking&nbsp; semaphores, posting to a queue, etc. is ~10 us.&nbsp; Also I basically agree with the theory you put forth in post #22.&nbsp; I have tried using portEND\_SWITCHING\_ISR and did not have any luck.&nbsp; I tried this early on and really thought it would be my solution.&nbsp;

To Edwards3:  
I am not using global variables to sychronize the ISR and tasks.&nbsp; By status checks I am referring to the RTOS performing actions such as checking for new messages on the queue, if there are pending tasks, etc. before entering my idle sleep mode.&nbsp; The 200 us came from toggling a GPIO pin when I entering the queueReceive function (to re-block on the queue after the second interrupt) and just prior to entering my idle sleep mode.&nbsp; In the process of configuring what power state I will be in while asleep I am setting the RTC overflow count.&nbsp; If there are no pending tasks, etc. the RTC count is set to \>\> 1 s.&nbsp;

[Previous page](https://forums.freertos.org/t/unexpected-task-behav-when-blocked-on-a-queue/1736.md?page=1)