Electronic – RTOS: Why Do We Need Special Post versions for ISRs

embeddedfreertosisrrtos

In some RT kernels, if you want to post to a semaphore or flag from an ISR, you need to call an special version of the method, instead of the regular one called from a normal task. Examples:

However there are other kernels where this is not needed. For instance:

  • OSSemPost() in uC/OS can be called both from tasks and ISRs.
  • release() in mbed-rtos, can be called from Threads and ISRs.
  • semGive() in VxWorks seems to be callable from an ISR according to the docs, and at first glance no special method exists for ISRs.

Why would you need to create special versions? I understand that the posting of a semaphore or flag might cause a blocked task of higher priority to be awaken. And that's why the scheduler is most likely going to run when the ISR exit callback is called (I'm talking about those functions needed to be called when you want to use kernel code inside the ISR, like portEXIT_SWITCHING_ISR() in FreeRTOS, or OSIntExit in uC/OS). So why the special post method in addition to the ISRexit call?

Best Answer

I've been reading the source code of both FreeRTOS and CoOS.

In FreeRTOS (the port I found first in Google), the xSemaphoreGiveFromISR() function calls to xQueueGenericSendFromISR(), and this function had this comment:

/* Similar to xQueueGenericSend, except we don't block if there is no room
    in the queue.  Also we don't directly wake a task that was blocked on a
    queue read, instead we return a flag to say whether a context switch is
    required or not (i.e. has a task with a higher priority than us been woken
    by this post). */

As for CoOS, the function isr_PostSem called from an ISR just enqueues a request to the so called "Service request queue", using the function InsertInSRQ. I have no idea about what this queue is, probably is some system task to offload work from ISRs and thus let interrupts complete quickly.

As for mbed, which only has 1 version of the method, it is based on CMSIS RTOS, and there's a call to the function osSemaphoreRelease(). There's a comment about this and similar functions:

The following CMSIS-RTOS functions can be called from threads and interrupt
service routines (ISR):
  - osSignalSet
  - osSemaphoreRelease
  - osPoolAlloc, osPoolCAlloc, osPoolFree
  - osMessagePut, osMessageGet
  - osMailAlloc, osMailCAlloc, osMailGet, osMailPut, osMailFree

Functions that cannot be called from an ISR are verifying the interrupt
status and return in case that they are called from an ISR context the status
code osErrorISR. In some implementations this condition might be caught using
the HARD FAULT vector.

So it seems to be just kernel design, some designers chose to have separate functions and let the programmer make the distinction, and some others prefered to have just one method and internally check if the call was made from an ISR.

Related Topic