The underlying mechanism of blocking versus polling a semaphore or queue?
Polling (timeout == 0): the call will only try to take the semaphore and return pdTRUE (non-zero) if it was successfully taken, otherwise pdFALSE (zero).
Blocking (timeout > 0): the call will also try to take the semaphore and if it succeeds, it will return immediately. If it can not be taken, then the timeout parameter determines the maximum number of clock ticks before waiting will be given up. While waiting, it will not consume any
CPU time, whereas the polling method does take CPU time.
portMAX_DELAY (e.g. 0xffff) is a so-called sentinel value, it doesn’t mean 65535 clock-ticks, but it is treated as “for ever”.
In the interrupt handling situation should I wait forever or
should I poll the semaphore in the interrupt handler to make
the interrupt latency as little as possible considering the
interrupt handler has the highest priority?
The interrupt latency, i.e. the time between the interrupt (hardware) signal and the time that your IRQ handler becomes active, is not really influenced by your coding style. The latency depends on other competing interrupts, except when you use critical sections like here:
extern volatile uint32t ulCounterIRQ;
// Execution of IRQ’s is temporarily disabled
// work safely with variables which can also be accessed
// by your IRQ handler
If you think well about your design, the use of critical sections can often be avoided. There are many locking mechanisms, other than disabling interrupts.
If I wait forever on the semaphore, does it not make the
No, why? Your call will return as soon as the semaphore can be taken by your task, even if it has to wait for a year 🙂
Personally, I would not use the “for ever” option. I would rather use a 1 sec timeout so that I can see that a task is still alive. It is hard to distinguish a permanently blocked task from a task that has got blocked because of stack corruption.
In a big embedded application, you might have many events from different sources. It would be expensive to create a new task with a new semaphore for every event. In stead you could make a task which receives commands, in stead of waiting for a semaphore:
void serverTask (void *pvParameters)
// Create a queue capable of containing 10 uint32_t values.
xServerQueue = xQueueCreate( 10, sizeof( uint32_t ) );
for ( ; ; )
if( xQueueReceive( xServerQueue, &ulCommand, 1000 ) )
switch( ulCommand )
Now every other task and every interrupt may send messages to the above task, using either QueueSend() or xQueueSendFromISR().
If you want to read more about FreeRTOS and the above subjects, you can find a really great manual/tutorial on http://shop.freertos.org