FastSemaphore
FastSemaphores differ from classic semaphores in the following ways:
- There is no initial count.
- There is no max count.
- There is an auto release count that is passed to RtInitializeFastSemaphore. This count represents the number of concurrent waiters that causes a simultaneous release. For example, if auto release count is set to 4 and 4 threads call RtAcquireFastSemaphore, all threads will release the wait once the fourth one is called.
- A thread that calls RtAcquireFastSemaphore uses a busy-wait. As a result, it should not be used on the first processor, as it will interfere with eRTOS kernel.
- Because it does not use the Process object layer, there is no way to create a named fast semaphore.
- There is a RtReleaseAllFastSemaphore API that can be used to release all waiters at once.
Since there are no objects associated with FastSemaphores, there are a number of restrictions that developers should be aware of before using a FastSemaphore:
- All threads sharing a FastSemaphore must be in the same process.
- All threads should have access to the same semaphore variable. In other words, it cannot be defined in a thread scope. The semaphore variable must be allocated for the duration of all busy-waits.
- The controlling process must not be terminated while a wait is active.
- All waiting threads must exit before the process exits or the process may hang.
- The developer must carefully manage thread priorities. Threads are not protected by priority inversion protocols.
- FastSemaphore relies on a busy wait, so you should disable watchdog monitoring since a FastSemaphore can trigger an unintentional Starvation exception.
- Threads sharing a FastSemaphore should execute on different processors to ensure that:
- A busy-wait thread does not interfere with the FastSemaphore release thread.
- A high priority busy-wait thread does not interfere with a lower priority FastSemaphore release thread.
Note: Internal objects are created from the system's internal allocation space (IntMSpace).
Topics:
