1. sometimes , one task want to yield to another task by calling taskYIELD(). But before the task do it, the ISRs maybe have taked place and yield to another in the end of the ISRs. So when control return to that task which will call taskYIELD(), it is unnecessary to yield again.

method to solve it : using context count
// how to use context count
taskENTER_CRITICAL();
..... do something else....
xSavedContextCount = xTaskContextCount(); // get the current Context change Count
taskEXIT_CRITICAL();
taskYIELD(xSavedContextCount);

//changed taskYIELD()
taskYIELD(portBASE_TYPE xSavedContextCount)
{
__taskENTER_CRITICAL();
__if (xTaskContextCount() != xSavedContextCount)
__{
____// go on yield
__}
__ taskEXIT_CRITICAL();
}


2.
in vTaskDelayUntil , vTaskDelay
at line 308 in xQueueSend
at line 437 in xQueueReceive ,

there are some code like below

vTaskSuspendAll();
......
if( !xTaskResumeAll() )
{
__taskYIELD();
}

but it's not completely appropriate to call taskYIELD() when xTaskResumeAll() return pdFALSE because before calling taskYIELD() ISRs maybe also put the current task in the Readylist. So its need not yield again and current task has meet it's requirement and can go on.
So these code can be

vTaskSuspendAll();
......
xTaskResumeAll() ;
if (current task is not in the readylist)
{
__taskYIELD();
}

these method may be useful. :)

Thanks for the suggestions. They are both of coarse valid, but also both carry an overhead. Which is best is of coarse a matter of opinion, or even a matter of the type of system you are working on.

For example, the xSavedContextCount count method requires another function call (to get the xsavedContextCount) and interrupts to be disabled/enabled, but would save an unwanted switch. Which is best will be application or processor dependent, and also depend on how often the unwanted switch would actually occur.

In the second case the line:

if (current task is not in the readylist)

would required a pointer comparison. This is no problem on say an ARM, but can be costly on low en 8bit devices.


I would be interested in knowing a bit more about who you are and what your experiences are. Why not drop me an email to the address on the FreeRTOS.org site (r dot barry at freert ..... ). Your input has been very helpful.

Regards.