| Wait | Waits on a condition variable |
| Signal | Signals the condition variable on the presence of a condition |
| Broadcast | Signals to all waiting tasks the presence of a condition |
The create operation creates a condition variable and initializes its internal control block.
The wait operation allows a task to block and wait for the desired conditions to occur in the shared resource. To invoke this operation, the task must first successfully acquire the guarding mutex. The wait operation puts the calling task into the task-waiting queue and releases the associated mutex in a single atomic operation.
The signal operation allows a task to modify the condition variable to indicate that a particular condition has been created in the shared resource. To invoke this operation, the signaling task must first successfully acquire the guarding mutex. The signal operation unblocks one of the tasks waiting on the condition variable. The selection of the task is based on predefined criteria, such as execution priority or system-defined scheduling attributes. At the completion of the signal operation, the kernel reacquires the mutex associated with the condition variable on behalf of the selected task and unblocks the task in one atomic operation.
The broadcast operation wakes up every task on the task-waiting list of the condition variable. One of these tasks is chosen by the kernel and is given the guarding mutex. Every other task is removed from the task- waiting list of the condition variable, and instead, those tasks are put on the task-waiting list of the guarding mutex.
8.5.3 Typical Uses of Condition Variables
Listing 8.1 illustrates the usage of the wait and the signal operations.
Listing 8.1: Pseudo code for wait and the signal operations.
Task 1
Lock mutex
Examine shared resource
While (shared resource is Busy)
WAIT (condition variable)
Mark shared resource as Busy
Unlock mutex
Task 2
Lock mutex
Mark shared resource as Free
SIGNAL (condition variable)
Unlock mutex
Task 1 on the left locks the guarding mutex as its first step. It then examines the state of the shared resource and finds that the resource is busy. It issues the wait operation to wait for the resource to become available, or free. The free condition must be created by task 2 on the right after it is done using the resource. To create the free condition, task 2 first locks the mutex; creates the condition by marking the resource as free, and finally, invokes the signal operation, which informs task 1 that the free condition is now present.
A signal on the condition variable is lost when nothing is waiting on it. Therefore, a task should always check for the presence of the desired condition before waiting on it. A task should also always check for the presence of the desired condition after a wakeup as a safeguard against improperly generated signals on the condition variable. This issue is the reason that the pseudo code includes a while loop to check for the presence of the desired condition. This example is shown in Figure 8.15.
Figure 8.15: Execution sequence of wait and signal operations.
8.6 Points to Remember
Some points to remember include the following:
· Pipes provide unstructured data exchange between tasks.
· The select operation is allowed on pipes.
· Event registers can be used to communicate application-defined events between tasks.
· Events of the same type are not accumulated in the event register.
· The occurrence of an event in the event register does not change the execution state of the receiving task, unless the task is already waiting on that event.
· Tasks receive signals synchronously.
· The occurrence of a signal changes the execution state of the receiving task.
· Signals can be handled by user-defined actions or by system-defined default actions.
· Multiple occurrences of the same signal are not cumulative.
· A condition variable allows one task to wait until another task has placed a shared resource in a desired state or condition.
· A condition variable is used to synchronize between tasks but is not used as a mechanism to synchronize access to shared resources.
Chapter 9: Other RTOS Services
9.1 Introduction
A good real-time embedded operating system avoids implementing the kernel as a large, monolithic program. The kernel is developed instead as a micro-kernel. The goal of the micro-kernel design approach is to reduce essential kernel services into a small set and to provide a framework in which other optional kernel services can be implemented as independent modules. These modules can be placed outside the kernel. Some of these modules are part of special server tasks. This structured approach makes it possible to extend the kernel by adding additional services or to modify existing services without affecting users. This level of implementation flexibility is highly desirable. The resulting benefit is increased system configurability because each embedded application requires a specific set of system services with respect to its characteristics. This combination can be
