Qing Li - Real-Time Concepts for Embedded Systems

unlock_mutex(&rwlock-›guard_mutex);

}

Listing 15.9 shows the code that the reader task invokes to acquire and release the lock.

Listing 15.9: Code called by the reader task to acquire and release locks.

acquire_read(rwlock_t *rwlock) {

lock_mutex(&rwlock-›guard_mutex);

rwlock-›r_waiting++;

while (rwlock-›rw_count ‹ 0)

wait_cond(&rwlock-›read_condvar,&rwlock-›guard_mutex);

rwlock-›r_waiting = 0;

rwlock-›rw_count++;

unlock_mutex(&rwlock-›guard_mutex);

}

release_read(rwlock_t *rwlock) {

lock_mutex(&rwlock-›guard_mutex);

rwlock-›rw_count--;

if (rwlock-›rw_count == 0)

signal_cond(&rwlock-›write_condvar,&rwlock-›guard_mutex);

unlock_mutex(&rwlock-›guard_mutex);

}

In case broadcast_cond does not exist, use a for loop as follows

for (i = rwlock-›read_waiting; i › 0; i--)

signal_cond(&rwlock-›read_condvar,&rwlock-›guard_mutex);

Some points to remember include the following:

· Synchronization is classified into resource and activity synchronization.

· Resource synchronization is closely related to critical sections and mutual exclusion.

· Activity synchronization is also called condition synchronization or sequence control.

· Barrier synchronization can be used to perform activity synchronization for a group of tasks.

· Rendezvous synchronization is used to perform activity synchronization between two tasks.

· Tasks communicate with each other to transfer data, to signal event occurrences, to allow one task to control other tasks, to synchronize activities, and to implement custom resource synchronization protocols.

· Interrupt locks should be used only when necessary to synchronize access to shared resources between a task and an ISR.

· Preemption locks can cause priority inversion.

Most embedded RTOSes facilitate a multitasking- or multithreading-capable environment. Many challenging design problems arise when developing embedded applications in multitasking systems.

The nature of this environment is that multiple threads of execution share and contend for the same set of resources. As such, resource sharing requires careful coordination to ensure that each task can eventually acquire the needed resource or resources to continue execution.

In a preemptive multitasking environment, resource sharing is a function of task priority. The higher the priority of a task, the more important the task is. Higher priority tasks have precedence over lower priority tasks when accessing shared resources. Therefore, resource sharing cannot violate this rule. On the other hand, if higher priority tasks always take resources from lower priority tasks, this sharing scheme is not fair and can prevent lower priority tasks from ever completing. This condition is called starvation. Maximization of resource utilization is yet another conflicting requirement.

Two of the most common design problems facing embedded developers are the deadlock and the priority inversion problem.

Specifically, this chapter focuses on:

· resource classification,

· resource request models,

· definition of deadlocks,

· deadlock detection, recovery, avoidance and prevention,

· definition of priority inversion, and

· solutions to priority inversion.

In embedded systems, resources are shared among various concurrently executing tasks. Examples of these shared resources include I/O devices, machine registers, and memory regions. These shared resources are categorized as either preemptible or nonpreemptible .

A preemptible resource can be involuntarily and temporarily removed from a task without affecting the task's execution state or result. The machine registers set that is shared among multiple tasks is an example. When kernel scheduling preempts a current task, the content of the machine registers, including the execution state of the current task, is saved into main memory. The registers are reinitialized to execute another task. When that other task completes, the execution state is restored to the register set, and the preempted task is resumed. The scheduler guarantees that the register set contains the execution state from a single task even though the registers are shared among multiple tasks throughout the system's lifetime.

A non-preemptible shared resource must be voluntarily relinquished by the owning task, or unpredictable results can occur. A shared memory region belongs to this category. For example, one task should not be allowed to write to a shared memory region before another task completes its read or write operation.

The types of resources a task holds are important when deciding on what solutions to take when the task is involved in deadlock situations. Section 16.3.3 discusses the relationship between the resource types and deadlock recovery mechanisms in detail.

Deadlock is the situation in which multiple concurrent threads of execution in a system are blocked permanently because of resource requirements that can never be satisfied.

A typical real-time system has multiple types of resources and multiple concurrent threads of execution contending for these resources. Each thread of execution can acquire multiple resources of various types throughout its lifetime. Potential for deadlocks exist in a system in which the underlying RTOS permits resource sharing among multiple threads of execution. Deadlock occurs when the following four conditions are present:

Mutual exclusion- A resource can be accessed by only one task at a time, i.e., exclusive access mode.

No preemption- A non-preemptible resource cannot be forcibly removed from its holding task. A resource becomes available only when its holder voluntarily relinquishes claim to the resource.

Hold and wait- A task holds already-acquired resources, while waiting for additional resources to become available.

Circular wait- A circular chain of two or more tasks exists, in which each task holds one or more resources being requested by a task next in the chain.

Given that each resource is nonpreemptible and supports only exclusive access mode, Figure 16.1 depicts a deadlock situation between two tasks.

Figure 16.1: Deadlock situation between two tasks.

Figure 16.1 is a resource graph. An arrow labeled holds going from a resource to a task indicates that the task currently holds (or owns) the resource. An arrow labeled wants going from a task to a resource indicates that the task currently needs this resource to resume execution.

In this example, task #1 wants the scanner while holding the printer. Task #1 cannot proceed until both the printer and the scanner are in its possession. Task #2 wants the printer while holding the scanner. Task #2 cannot continue until it has the printer and the scanner. Because neither task #1 nor task #2 is willing to give up what it already has, the two tasks are now deadlocked because neither can continue execution.