What happens when Semaphore is released or signaled in RTOS?

Question

Let there be 6 tasks, out of 6, 4 (task) are waiting for a Semaphore. When a semaphore is signaled, what decision is made by RTOS

1. which tasks to pick from the waiting(for semaphore) list
   
2. if one task is picked from the waiting list what will happen to remaining task i.e when will they run.
   
3. when already a higher priority task is running.
   

Is the solution same across all RTOS

Answer 1

If this is a priority-based, preemptive multitasking system then the RTOS scheduler will run the highest priority task that is ready-to-run. When the semaphore is signaled, the RTOS scheduler re-evaluates what the highest priority ready-to-run task is and it will perform a context switch to that task if it is different from the previously running task.

When there are multiple tasks waiting for the same semaphore and that semaphore is signaled then:

1. The highest priority task of the tasks waiting for the semaphore will be made ready-to-run.
2. The remaining tasks will continue to wait for the semaphore.
3. If the previously running task is higher priority than the task that was made ready-to-run then the previously running task continues to run. Even though a waiting task was made ready-to-run, it will not run until it becomes the highest priority task that is ready-to-run.

The above is true for all priority-based preemptive multitasking RTOS, which is not necessarily all RTOS. If an RTOS does not support prioritized tasks then it likely awards the semaphore to the task that has been waiting for the semaphore the longest. And it also probably uses a round-robin scheduler such that each task runs in a predetermined time slot rather than allowing the tasks to preempt each other asynchronously.

Follow-up: If you are using the semaphore as an event signal, and there are multiple tasks that consume the event, then you're going to have to think carefully about the design. I don't believe this can be done with a single binary semaphore. Because if the highest priority consumer task gets the semaphore, does its business, and then waits for the semaphore again before the semaphore is signaled again, then the highest priority consumer will always get the semaphore every time it is signaled. The lower priority consumer tasks will never run because they'll never be awarded the semaphore.

One possible solution is to use a counting semaphore. When the event occurs the semaphore count should be set equal to the number of consuming tasks. Then each consuming task gets the semaphore and decrements the count by one. The consuming tasks should not wait on the semaphore again until the semaphore count has been reduced to zero. This will prevent the highest priority consumer from getting the semaphore multiple times per event and therefore it will allow each consumer task to run exactly once in response to the event.

You might want to explore publish-subscribe design patterns to see if there are better ways of solving this requirement for your situation.