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)…
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.
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.
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.