multiple tasks receiving from same queue

hooverphonique wrote on Tuesday, November 11, 2008:


what the title says, is that possible? and if so, will they all get served if at the same priority?

if it works, i guess a binary semaphore can have multiple tasks waiting to "take" it also?

i have 2 scenarios i want to solve with this:

1. have multiple tasks for picking lengthy jobs off a job queue.

2. have an interrupt "give" a binary semaphore and then have whichever task that is "woken up" figure out what the event that caused the interrupt was and then just give the semaphore back and yield if the event was for another task (the code that decides what the event was cannot be run inside an isr)…


davedoors wrote on Tuesday, November 11, 2008:

It is definitely possible, and the tasks get served in priority order. If a high and low priority task are blocked on the same queue and data arrives the high priority task will get the data, if the high priority task reads the queue again without blocking in between then it will also get the next data. If the high priority task blocks or delays, then the low priority task is the only task waiting on data and will get the next data to arrive.

hooverphonique wrote on Tuesday, November 11, 2008:

That’s great… Too bad the documentation doesn’t mention that this is permitted/possible at all.

hooverphonique wrote on Wednesday, November 12, 2008:

another question:

if a task gives a semaphore that another task of the same priority is blocking to take, is the first one then preempted?


richard_damon wrote on Wednesday, November 12, 2008:

While I am not certain if there is a preemption at this point, I will point out that depending on it either way is probably a bug, since you might get a timer tick task change right afterward and get effectively the opposite behavior.

rtel wrote on Wednesday, November 12, 2008:

If a task of priority x unblocks a task also of the same priority x then the unblocked task will be the next to run:

if( pxUnblockedTCB->uxPriority >= pxCurrentTCB->uxPriority )
    /* Return true if the task removed from the event list has
    a higher priority than the calling task.  This allows
    the calling task to know if it should force a context
    switch now. */
    xReturn = pdTRUE;

but as both tasks are the same priority then the scheduler is at liberty to choose either to run without breaking its requirements.