incrediball wrote on Friday, January 23, 2009:

The documentation states the following: "API functions that have the potential to cause a context switch must not be called while the scheduler is suspended". Does this include interrupts that call portYIELD_FROM_ISR? For example if xSemaphoreGiveFromISR is called and the parameter pxHigherPriorityTaskWoken is set to pdTRUE should portYIELD_FROM_ISR NOT be called if the scheduler is currently suspended?

If this is the case then this should perhaps be explicitly noted because code between vTaskSuspendAll and xTaskResumeAll may not be calling any API functions and the problem would not be very obvious…

rtel wrote on Friday, January 23, 2009:

There is no problem with interrupts attempting to yield while the scheduler is suspended, or interrupts reading and writing to queues/semaphores.  The scheduler takes care of these situations.

If an interrupts attempts to yield then the yield is held pending until the scheduler is resumed.  Pending yields are actually performed within xTaskResumeAll().


incrediball wrote on Monday, January 26, 2009:

In that case would it be possible to allow yields and calls to functions that can cause context switches between vTaskSuspendAll and xTaskResumeAll? These would just become pending yields in the same way as with yields in an ISR. Then the only thing that wouldn’t be allowed would be blocking calls.

Just an idea. Not sure how useful this would be…

rtel wrote on Monday, January 26, 2009:

In some cases it is ok to yield when the scheduler is suspended, and in some cases not, hence the statement you referred to about not doing it.

Sometimes the logic of a program relies on a yield being performed at the correct time.  The queue code is one place this is the case (when the queue is empty or full - it would make no sense for a yield at this time to be pended - also when deleting a task, once the tasks has been deleted a yield must occur away from the task, there are other examples).