FastSemaphores differ from classic semaphores in the following ways:
- There is no initial count.
- There is no max count.
- An auto release count is passed to RtInitializeFastSemaphore. This count represents the number of concurrent waiters that cause a simultaneous release. For example, if the 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 RTSS processor, as it will interfere with the wRTOS Subsystem.
- Because it does not use the RTSS object layer, there is no way to create a named fast semaphore. This also means it will not appear in RtObjects output or wRTOS WinDbg extension information.
- There is a RtReleaseAllFastSemaphore API that can release all waiters at once.
Since there are no objects associated with FastSemaphores, there are several restrictions that developers should be aware of before using a FastSemaphore:
- All threads sharing a FastSemaphore must be reside 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. Priority inversion protocols do not protect threads.
- 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 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:
