multiple tasks receiving from same queue

Hi, 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).. cheers, hoover

multiple tasks receiving from same queue

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.

multiple tasks receiving from same queue

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

multiple tasks receiving from same queue

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? cheers

multiple tasks receiving from same queue

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.

multiple tasks receiving from same queue

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. Regards.