6.3.2 Acquiring and Releasing Semaphores
Table 6.2 identifies the operations used to acquire or release semaphores.
Table 6.2: Semaphore acquire and release operations.
| Operation | Description |
|---|---|
| Acquire | Acquire a semaphore token |
| Release | Release a semaphore token |
The operations for acquiring and releasing a semaphore might have different names, depending on the kernel: for example,
Tasks typically make a request to acquire a semaphore in one of the following ways:
· Wait forever - task remains blocked until it is able to acquire a semaphore.
· Wait with a timeout - task remains blocked until it is able to acquire a semaphore or until a set interval of time, called the
· Do not wait - task makes a request to acquire a semaphore token, but, if one is not available, the task does not block.
Note that ISRs can also release binary and counting semaphores. Note that most kernels do not support ISRs locking and unlocking mutexes, as it is not meaningful to do so from an ISR. It is also not meaningful to acquire either binary or counting semaphores inside an ISR.
Any task can release a binary or counting semaphore; however, a mutex can only be released (unlocked) by the task that first acquired (locked) it. Note that incorrectly releasing a binary or counting semaphore can result in losing mutually exclusive access to a shared resource or in an I/O device malfunction.
For example, a task can gain access to a shared data structure by acquiring an associated semaphore. If a second task accidentally releases that semaphore, this step can potentially free a third task waiting for that same semaphore, allowing that third task to also gain access to the same data structure. Having multiple tasks trying to modify the same data structure at the same time results in corrupted data.
6.3.3 Clearing Semaphore Task-Waiting Lists
To clear all tasks waiting on a semaphore task-waiting list, some kernels support a
Table 6.3: Semaphore unblock operations.
| Operation | Description |
|---|---|
| Flush | Unblocks all tasks waiting on a semaphore |
The flush operation is useful for broadcast signaling to a group of tasks. For example, a developer might design multiple tasks to complete certain activities first and then block while trying to acquire a common semaphore that is made unavailable. After the last task finishes doing what it needs to, the task can execute a semaphore flush operation on the common semaphore. This operation frees all tasks waiting in the semaphore’s task waiting list. The synchronization scenario just described is also called
6.3.4 Getting Semaphore Information
At some point in the application design, developers need to obtain semaphore information to perform monitoring or debugging. In these cases, use the operations shown in Table 6.4.
Table 6.4: Semaphore information operations.
| Operation | Description |
|---|---|
| Show info | Show general information about semaphore |
| Show blocked tasks | Get a list of IDs of tasks that are blocked on a semaphore |
These operations are relatively straightforward but should be used judiciously, as the semaphore information might be dynamic at the time it is requested.
6.4 Typical Semaphore Use
Semaphores are useful either for synchronizing execution of multiple tasks or for coordinating access to a shared resource. The following examples and general discussions illustrate using different types of semaphores to address common synchronization design requirements effectively, as listed:
