To be able to efficiently block anywhere in the task code, a conventional real-time kernel maintains relatively complex execution contexts—including separate stack spaces—for each running task, as shown in Figure 6.2 in Chapter 6. Keeping track of the details of these contexts and switching among them requires lots of bookkeeping and sophisticated mechanisms to implement the context switch magic. In contrast, an RTC kernel can be ultra simple because it doesn't need to manage multiple stacks and all the associated bookkeeping.

By requiring that all tasks run to completion and enforcing fixed-priority scheduling, an RTC kernel can instead manage all context information using the machine's natural stack protocol. Whenever a task posts an event to a higher-priority task, an RTC kernel uses a regular C function call to build the higher-priority task context on top of the preempted-task context. Whenever an interrupt preempts a task and the interrupt posts an event to a higher-priority task, the RTC kernel uses the already established interrupt stack frame on top of which to build the higher-priority task context, again using a regular C function call.

This simple form of context management is adequate because every task, just like every ISR, runs to completion. Because the preempting task must also run to completion, the lower-priority context will never be needed until the preempting task (and any higher-priority tasks that might preempt it) has completed and returned—at which time the preempted task will, naturally, be at the top of the stack, ready to be resumed.

At this point, it is interesting to observe that most prioritized interrupt controllers (e.g., the 8259A inside the PC, the AIC in AT91-based ARM MCUs from Atmel, the NVIC in ARM Cortex-M3, and many others) implement in hardware the same asynchronous scheduling policy for interrupts as an RTC kernel implements in software for tasks. In particular, any prioritized interrupt controller allows only higher-priority interrupts to preempt currently serviced interrupt. All interrupts must run to completion and cannot “block.” All interrupts nest on the same stack.

This close similarity should help you understand the operation of an RTC kernel because it is based on exactly the same principle widely used and documented in hardware design (just pick up a datasheet of any aforementioned microprocessors). Also, the similarity further reinforces the symmetry between RTC tasks and interrupts illustrated in Figure 6.9 in Chapter 6.

One obvious consequence of the simplistic stack-management policy, and the most severe limitation of an RTC kernel, is that the RTC tasks cannot block. The kernel cannot leave a high-priority task context on the stack and at the same time resume a lower-priority task. The lower-priority task context simply won't be accessible on top of the stack unless the higher-priority task completes. Of course the inability to block disqualifies an RTC kernel for use with the traditional sequential programming paradigm, which is all about blocking and waiting for events at various points in the task's code.

But the inability to block in the middle of an RTC step is not really a problem for event-driven active objects because they don't need to block anyway. In other words, an active object computing model can benefit from the simplicity and excellent performance of an RTC kernel while being insensitive to the limitations of such a kernel.

As a fully preemptive multitasking kernel, an RTC kernel must ensure that at all times the CPU executes the highest-priority task that is ready to run. Fortunately, only two scenarios can lead to readying a higher-priority task:

Figure 10.1 illustrates the synchronous preemption scenario caused by posting an event from a low-priority task to a high-priority task.

Figure 10.1. Synchronous preemption by a high priority task in an RTC kernel.

Obviously, the synchronous preemption is not limited to only one level. If the high-priority task posts or publishes events to a still higher-priority task in point 5 of Figure 10.1, the high-priority task will be synchronously preempted and the scenario will recursively repeat itself at a higher level of nesting.

Figure 10.2 illustrates the asynchronous preemption scenario caused by an interrupt.

Figure 10.2. Asynchronous preemption by an interrupt and a high-priority task in an RTC kernel.

It is important to point out that conceptually the interrupt handling ends in the RTC kernel-specific interrupt exit (5), even though the interrupt stack frame still remains on the stack and the IRET instruction has not been executed yet. The interrupt ends because the EOI instruction is issued to the interrupt controller. Before the EOI instruction, the interrupt controller allows only interrupts of higher priority than the currently serviced interrupt. After the EOI instruction followed by the call to the RTC scheduler, the interrupts get unlocked and the interrupt controller allows all interrupt levels, which is exactly the behavior expected at the task level.

Consequently, the asynchronous preemption is not limited to only one level. The high-priority task runs with interrupts unlocked (Figure 10.2(8)), so it too can be asynchronously preempted by an interrupt, including the same level interrupt as the low-priority task in step 2. If the interrupt posts or publishes events to a still higher-priority task, the high-priority task will be asynchronously preempted and the scenario will recursively repeat itself at a higher level of nesting.

Charting the stack utilization over time provides another, complementary view of the synchronous and asynchronous preemption scenarios depicted in Figures 10.1 and 10.2, respectively. To demonstrate the essential behavior, I ignore the irrelevant function calls and other unrelated stack activity.

Figure 10.3 illustrates the stack utilization across the synchronous preemption scenario. The timeline and labels used in Figure 10.3 are identical to those used in Figure 10.1 to allow you to easily correlate these two diagrams.

Figure 10.3. Stack utilization during the synchronous preemption scenario.

Figure 10.4 illustrates the stack utilization during the asynchronous preemption scenario. The time-line and labels used in Figure 10.4 are identical to those used in Figure 10.2 to enable easy correlating of these two diagrams.

Figure 10.4. Stack utilization during the asynchronous preemption scenario.

As you can see, all context (both the interrupt and task contexts) are kept in a single stack. This forces the kernel to be nonblocking. The scheduler can never access anything but the topmost context in the stack. Thus, the scheduler can only choose from two alternatives: launch a new task or resume the topmost task context saved in the stack.

If you have some experience with traditional preemptive kernels, an RTC kernel will require some getting used to and perhaps rethinking some basic semantics of the “task” and “interrupt” concepts.

Conventional preemptive kernels maintain separate stack spaces for each running task, as explained in Chapter 6. Keeping track of the details of these contexts and switching among them requires a lot of bookkeeping and sophisticated mechanisms to implement the context switch. In general, an ISR stores the interrupt context on one task's stack and restores the context from another task's stack. After restoring the task's context into the CPU registers, the traditional scheduler always issues the IRET³ The IRET instruction is understood here generically and means the instruction that causes the return from interrupt. instruction. The key point is that the interrupt context remains saved on the preempted task's stack, so the saved interrupt context outlives the duration of the interrupt handler. Therefore, defining the duration of an interrupt from saving the interrupt context to restoring the context is problematic.

The situation is not really that much different under an RTC kernel, such as QK. An ISR stores the interrupt context on the stack, which happens to be common for all tasks and interrupts. After some processing, the ISR issues the EOI⁴ The EOI instruction is understood here generically and denotes a specific machine instruction to stop prioritizing the current interrupt nesting level. instruction to the interrupt controller and calls the RTC scheduler. If no higher-priority tasks are ready to run, the scheduler exits immediately, in which case the ISR restores the context from the stack and executes the IRET instruction to return to the original task exactly at the point of preemption. Otherwise, the RTC scheduler unlocks interrupts and calls a higher-priority task. The interrupt context remains saved on the stack, just as in the traditional kernel.

The point here is that the ISR is defined from the time of storing interrupt context to the time of issuing the EOI instruction and enabling interrupts inside the RTC scheduler, not necessarily to the point of restoring the interrupt context via the IRET instruction. This definition is more precise and universal because under any kernel the interrupt context remains stored on one stack or another and typically outlives the duration of an interrupt processing.

By managing all task and interrupt contexts in a single stack, an RTC kernel can run with far less RAM⁵ In one case of a specialized GPS receiver application, an RTC kernel brought almost 80 percent reduction of the stack space compared to a traditional preemptive kernel running the same event-driven application [Montgomery 06]. than a typical blocking kernel. Because tasks don't have private stacks, there is no unused private stack space associated with suspended tasks. Furthermore, a traditional kernel does not distinguish between the synchronous and asynchronous preemptions and makes all preemptions look like the more stack-intensive asynchronous preemptions. Finally, an RTC kernel does not need to maintain the task control blocks (TCBs; see Figure 6.2 in Chapter 6) for each task.

Because of this simplicity, context switches in an RTC kernel (especially the “synchronous preemptions”) can involve much less stack space and CPU overhead than in any traditional kernel. But even the “asynchronous preemptions” in an RTC kernel end up typically using significantly less stack space and fewer CPU cycles. A traditional kernel must typically save all CPU registers in strictly defined order and in “one swoop” onto the private task stack, to be able to restore the registers in an orderly fashion, also in “one swoop.” In contrast, an RTC kernel doesn't really care about the order of registers stored and whether they are stored in “one swoop” or piecemeal. The only relevant aspect is that the CPU state be restored exactly to the previous status, but it's irrelevant how this happens. This means that the basic ISR entry and exit sequences that most embedded C compilers are capable of generating are typically adequate for an RTC kernel while being inadequate for most traditional kernels. The C compiler is in a much better position to optimize interrupt stack frames for specific ISRs by saving only the actually clobbered registers and not saving the preserved registers. In this respect, an RTC kernel can take advantage of the C compiler capabilities whereas a traditional kernel can't.

The last point is perhaps best illustrated by a concrete example. All C compilers for ARM processors (I mean the traditional ARM architecture⁶ The new ARMv7 architecture (e.g., Cortex-M3) saves registers in hardware upon interrupt entry, so a C compiler is not involved. However, even in this case the hardware-generated interrupt stack frame takes into account the APCS because the hardware pushes only the eight clobbered ARM registers on the stack.) adhere to the ARM Procedure Call Standard (APCS) that prescribes which registers must be preserved across a C function call and which can be clobbered. The C compiler-generated ISR entry initially saves only the registers that might be clobbered in a C function, which is less than half of all ARM registers. The rest of the registers get saved later, inside C functions invoked from the ISR, if and only if such registers are actually used. This is an example of a context save occurring “piecemeal,” which is perfectly suitable for an RTC kernel. In contrast, a traditional kernel must save all ARM registers in “one swoop” upon ISR entry, and if an ISR calls C functions (which it typically does), many registers are saved again. Needless to say, such policy requires more RAM for the stacks and more CPU cycles for a context switch (perhaps by a factor of two) than an RTC kernel.

Listing 10.1 shows the directories and files comprising the QK preemptive kernel in C. The structure of the C++ version is almost identical, except the implementation files have the .cpp extension. The general source code organization of all QP components is described in Section 8.1.3 in Chapter 8.

The qk.h header file, shown in Listing 10.2, integrates the QK kernel with the QF framework. The structure of qk.h closely resembles the vanilla kernel header file qvanilla.h discussed in Section 7.11.2 in Chapter 7. The QK kernel uses many of the same basic building blocks provided in QF. Specifically, the QK kernel uses the native QF active object event queues (see Section 7.8.3 in Chapter 7), the QF native memory pool (see Section 7.9), and the QF priority set (see Section 7.10) to keep track of all active object event queues. Additionally, the central element of the QK design is the current systemwide priority, which is just a byte. Figure 10.5 shows the QK data elements.

Figure 10.5. Data elements used by the QK preemptive kernel.

Interrupt processing is always specific to your particular application, so obviously it cannot be programmed generically in a platform-independent manner. However, handling interrupts is critical to understanding how the QK kernel works, so here I explain it in general terms.

The most important thing you need to understand about interrupt processing under any preemptive kernel, not just QK, is that the kernel must be notified about entering and exiting an interrupt. Specifically, every interrupt must call the QK scheduler upon exit, to give the kernel a chance to handle the asynchronous preemption, as described in Section 10.2.3.

Unlike most conventional preemptive kernels, QK can typically work with interrupt service routines synthesized by the C compiler, which most embedded C cross-compilers support. Listing 10.3 shows the pseudocode for an ISR; Figure 10.6 shows the timeline for executing this code.

Figure 10.6. Timeline of servicing an interrupt and asynchronous preemption in QK. Black rectangles represent code executed with interrupts locked.

Figure 10.6 shows the timeline of interrupt servicing and asynchronous preemption under the QK preemptive kernel. I'd like to highlight two interesting points. First, the interrupt response under the QK kernel is as fast as under any other preemptive kernel and is mostly dominated by the longest critical section in the system and how long it takes the hardware to save the interrupt context to the stack. Second, the task-level response of the high-priority task is generally faster than any conventional preemptive kernel because the interrupt context does not need to be restored entirely from the stack and the interrupt return does not need to be executed to start the high-priority task. In the RTC kernel, all this is replaced by a function call, which typically is much faster than restoring the whole register set from the stack and executing the IRET instruction.

The source file qk_sched.c implements the QK scheduler, which is the most important part of the QK kernel. As explained in Section 10.2.3, the QK scheduler is called at two junctures: (1) when an event is posted to an event queue of an active object (synchronous preemption), and (2) at the end of ISR processing (asynchronous preemption). In the qk.h header file (Listing 10.2(14)), you saw how the QK scheduler gets invoked to handle the synchronous preemptions. In the previous section, you also saw how the scheduler gets called from an interrupt context to handle the asynchronous preemption. Here, I describe the QK scheduler itself.

The QK scheduler is simply a regular C-function QK_schedule_(), whose job is to efficiently find the highest-priority active object that is ready to run and to execute it, as long as its priority is higher than the currently serviced QK priority. To perform this job, the QK scheduler relies on two data elements: the set of tasks that are ready to run QK_readySet_ (Listing 10.2(4)) and the currently serviced priority QK_currPrio_ (Listing 10.2(5)).

Figure 10.5 shows the relationship between the QK data elements and QF active objects. The variable QK_currPrio_ is an integer of type uint8_t that holds the value of the currently serviced priority level. The QK ready-set QK_readySet_ is of type QPSet64 (see Section 7.10 in Chapter 7), which is capable of representing up to 64 elements numbered 1 through 64. As shown in Figure 10.5, each bit in the QK_readySet_ priority set represents one QF active object. The bit number n in QK_readySet_ is 1 if the event queue of the active object of priority n is not empty. Conversely, bit number m in QK_readySet_ is 0 if the event queue of the active object of priority m is empty or the priority level m is not used. Both variables QK_currPrio_ and QK_readySet_ are always accessed in a critical section to prevent data corruption.

Listing 10.4 shows the complete implementation of the QK_schedule_() function.

The qk.c source file, shown in Listing 10.5, defines the QK initialization, cleanup, startup, and idle loop.

QK is a preemptive kernel, and as with all such kernels, you must be very careful with any resource sharing among QK tasks. Ideally, the QF active objects (i.e., QK tasks) should communicate exclusively via events and otherwise should not share any resources, which I have been advocating all along (see Chapter 9). This ideal situation allows you to program all active objects without ever worrying about mutual exclusion mechanisms to protect shared resources.

However, at the cost of increased coupling among active objects, you might choose to share selected resources. If you go this path, you take the burden on yourself to interlock the access to such resources (shared memory or devices).

One powerful method of guaranteeing mutually exclusive access to resources at your disposal is the critical section mechanism implemented with the QF macros QF_INT_LOCK() and QF_INT_UNLOCK(), as described in Section 7.3 in Chapter 7. For very short accesses this might well be the most efficient synchronization mechanism.

However, you can also use a much less intrusive mechanism available in QK. QK supports a priority-ceiling mutex to prevent task-level preemptions while accessing a shared resource. Priority-ceiling mutex is immune to priority inversions [Kalinsky 05] but is a more selective mechanism than interrupt locking because all tasks (and interrupts) of priority higher than the priority ceiling run as usual. Listing 10.6 shows an example of using a QK mutex to protect a shared resource.

As you can see, the mutex variables are used only temporarily, and there is no limitation on how many mutexes you can use in your application. In principle, mutex locks can even nest, so your code in Listing 10.6(3) could use another priority-ceiling mutex. Note that I mention this only as a theoretical possibility, not necessarily as a good or recommended design.

Before explaining how the QK protects the resource and why it is a nonblocking mechanism, I simply show in Listing 10.7 how it is implemented.

As you can see, locking the mutex boils down to raising the current QK priority to the priority ceiling level. Recall that the QK scheduler can only launch tasks with priorities higher than the initial priority with which the scheduler was entered (Listing 10.4(11)). This means that temporarily increasing the current QK priority prevents preemptions from all tasks with priorities lower than or equal to the priority ceiling. This is exactly what a priority ceiling mutex is supposed to do to protect your resource.

Note that the QK mutex is a nonblocking mechanism. If a task that needs to protect a shared resource is running at all, it means that all tasks of higher priority have no events to process. Consequently, simply preventing launch of higher-priority tasks that might access the resource is sufficient to guarantee the mutually exclusive access to the resource. Of course, you don't need to worry about any lower-priority tasks that might be preempted because they never resume until the current task runs to completion.

Thread-local storage (TLS) is a mechanism by which variables are allocated such that there is one instance of the variable per extant thread. The canonical example of when TLS could be useful is the popular Newlib⁷ www.sourceware.org/newlib/ standard C runtime library intended for use in embedded devices. Newlib's facilities are reentrant, but only when properly integrated into a multithreaded environment [Gatliff 01]. Because QK is a preemptive kernel, care must be taken to preserve the reentrant character of Newlib.

For example, consider the errno facility specified in the ANSI C standard. The runtime library sets errno when an error occurs within the library. Once set, errno's value persists until the application clears it, which simplifies error notification by the library but can create reentrancy problems when multiple threads are using the library at the same time. If errno would be just a single global variable shared among all threads, neither thread would know who generated the error.

Newlib addresses this problem by redefining errno as a macro that (indirectly) references a global pointer called _impure_ptr (see Figure 10.7). The Newlib's _impure_ptr points to a structure of type struct _reent. This structure contains the traditional errno value specified by ANSI, but it also contains a lot of other elements, including signal handler pointers and file handles for standard input, output, and error streams.

Figure 10.7. Pointer to thread-local storage (TLS) switched around by the kernel.

The central idea of the Newlib design is that every thread in the application has its own copy of the _reent structure (shown as TLS in Figure 10.7) and that the _impure_ptr pointer is switched during context switches to always point at the _reent structure of the currently active thread. Obviously, to perform the switching of the _impure_ptr, you need a helping hand from the kernel.

QK supports the TLS concept by providing a context-switch hook QK_TLS(), which is invoked every time a different task priority is processed (see Listing 10.4(19,33)). The macro QK_TLS() receives from the kernel a pointer to the current active object. The following code fragment from qk_port.h defines the macro QK_TLS() for re-assigning the Newlib's _impure_ptr during context switches:

Though the QK_TLS() macro will switch the _impure_ptr automatically, you are responsible for allocating the _reent structure in each active object. You also need to tell QK where the TLS is for every active object during startup by passing the pointer to the TLS as the fifth parameter of the QActive_start() function (see Listing 10.5(17)).

The TLS support in QK is generic and allows you to handle any number of libraries like Newlib. In the upcoming Section 10.6, I provide the dining philosophers application example for QK, which demonstrates the switching of two “impure pointers” for two hypothetical reentrant libraries.

The C compiler-generated context save and restore for interrupts typically includes only the CPU core registers but does not include the registers of various coprocessors, such as floating-point coprocessors, specialized DSP engines, dedicated baseband processors, video accelerators, or other specialized coprocessors (perhaps implemented in FPGAs) that surround the CPU core. This ever-growing conglomerate of complex register architectures extends far beyond the core CPU registers, which poses a problem for a preemptive kernel if the various coprocessors are used by multiple tasks. The solution offered by advanced preemptive kernels is to include the various coprocessor registers in the context switch process, thus allowing sharing of the coprocessors among multiple tasks.

The QK kernel supports such extended context switch in a generic way, which you can easily customize for various coprocessors and hardware accelerators. The QK design of the extended context switch carefully minimizes the added overhead by saving and restoring the extended context only when necessary. The basic simplifying assumption is that neither ISRs, nor the QK idle loop use the coprocessor(s). Consequently, the extended context needs to be preserved only when a task preempts another task. Moreover, synchronous context switches generally don't need to be extended, because the context switch is in this case just a simple function call (see Section 10.2.3), which cannot happen in the middle of accessing a coprocessor.

This leaves only the asynchronous preemptions as really requiring the extended context switch. As described in Section 10.3.3, asynchronous preemptions are handled upon the exit from interrupts in the QK_ISR_EXIT() macro. Listing 10.8 shows pseudocode of the QK_ISR_EXIT() macro, which calls the extended scheduler QK_scheduleExt_() instead of QK_scheduler_(), as shown in Listing 10.3(10).

Figure 10.8 shows the additional extended context save and restore steps implemented in the extended scheduler QK_scheduleExt_(). The per-active object extended context is simply added to the TLS area, which is accessible via the thread data member of the QActive class.

Figure 10.8. Extended context switch saves and restores coprocessor registers in the TLS area.

Listing 10.9 shows the extended scheduler QK_scheduleExt_(). In the explanation section following this listing, I describe only the highlighted differences from the regular scheduler QK_scheduler_(), which I already explained in Listing 10.4.

The QK_EXT_SAVE() and QK_EXT_RESTORE() macros allow you to save and restore as many coprocessor contexts as necessary for a given task. As shown in Figure 10.8, you need to provide per-task memory for all the extended contexts that you use. In the next section, I describe the QK port to 80x86 with the 80x87 floating point coprocessor (FPU) and I provide examples of the macros QK_EXT_SAVE() and QK_EXT_RESTORE() for the 80x87 FPU.

Listing 10.10 shows the qep_port.h header file for 80x86/QK/Turbo C++ 1.01/Large memory model. The legacy Turbo C++ 1.01 is a prestandard compiler, so I typedef the six platform-specific exact-with integer types used in QP.

Listing 10.11 shows the qf_port.h header file for 80x86/QK/Turbo C++ 1.01/Large memory model. You always need to configure the maximum number of active objects QF_MAX_ACTIVE and you need to include qep_port.h, qk_porth.h, and qf.h header files.

The actual porting of QK to the CPU/Compiler of your choice happens in the qk_port.h header file. The first porting decision you need to make is the policy for locking and unlocking interrupts. To make this decision correctly, you need to learn a bit about your target CPU and the compiler to find out the most efficient way of enabling and disabling interrupts from C or C++. Generally, your first choice should be the safe policy of “saving and restoring the interrupt status” (Section 7.3.1 in Chapter 7). However, if you find out that it is safe to unlock interrupts inside ISRs because your target system can prioritize interrupts in hardware, you can use the simple and fast policy of “unconditional interrupt unlocking” (Section 7.3.2 in Chapter 7). With the fast policy you must always make sure that QF functions are invoked with interrupts unlocked, or more generally, that critical sections don't nest.

The next decision, related to the first, is the QK-specific interrupt entry and exit. Again, you need find out whether your CPU enters ISRs with interrupts locked or unlocked (most CPUs lock interrupts before vectoring to ISRs). If you decided to use the fast interrupt-locking policy, you must unlock interrupts in QK_ISR_ENTRY() and lock them again in QK_ISR_EXIT() to avoid nesting of critical sections when you call any QF services. If your system has an interrupt controller, you might decide to unlock interrupts inside ISRs even if you're using the safe policy of “saving and restoring interrupt context.” I would generally recommend leaving interrupts locked throughout the whole ISR on systems that don't have interrupt controllers. Obviously, in the latter case you must be using the safe policy of “saving and restoring interrupt context,” because most QF services that you call from ISRs use a critical section internally.

Finally, you need to customize the advanced features, such as the TLS and the extended context switch, if you plan to use them in your applications. Here, you need to find out which libraries require TLS support (e.g., Newlib). You also need to find what kind of coprocessors you want to support and how to save and restore their registers from C.

Listing 10.12 shows the qk_port.h header file for 80x86/QK/Turbo C++ 1.01/Large memory model. I decided to use the simple “unconditional interrupt unlocking” policy because the standard PC is equipped with the external 8259A Programmable Interrupt Controller (PIC) and the Turbo C++ 1.01 compiler provides the pair of functions disable() and enable(), to unconditionally lock and unlock interrupts, respectively. With this simple interrupt-locking policy, I must unlock interrupts in QK_ISR_ENTRY() and lock them again in QK_ISR_EXIT(). I also use the 80x87 floating point coprocessor (FPU) and two libraries that require TLS support.

The functions FPU_save() and FPU_restore(), declared in Listing 10.12(27,28), are part of the QK port. They are defined in the assembly file <qp>qpcports80x86qk cpp101lsrcfpu.asm. Both these functions are just shells for executing the 80x87 machine instructions FSAVE and FRSTOR, respectively.

As it turns out, an interesting asynchronous preemption is not that easy to observe in the DPP application. By an interesting preemption, I mean a task asynchronously preempting another task, as opposed to simply a task asynchronously preempting the idle loop. Figure 10.9 illustrates why. The DPP application is mostly driven by the system clock tick interrupt (ISR_tmr), which posts the time events to the Philosopher active objects. Typically, the interrupts and state machines execute so quickly that all processing happens very close to the clock tick and the CPU goes quickly back to executing the QK idle loop. With the code executing so fast, the ISR_tmr() has no chance to actually preempt any QK task, just the idle loop. Consequently an asynchronous preemption cannot happen.

Figure 10.9. Execution profile of the DPP application with QK.

Therefore, to increase the odds of asynchronous preemptions in this application, I have added the second interrupt (the ISR_kbd triggered by the keyboard), which is asynchronous with respect to the clock tick and always posts an event to the Table active object. I also added some artificial CPU loading in the form of various busy-wait functions called from to the state machines and interrupts (I show examples of these functions later in this section). Finally, I've instrumented the ISRs to report preemptions caused by interrupts to the screen.

Since I cannot foresee the speed of your CPU, I have provided a command-line parameter to the DPP application that determines the delay incurred by the various busy-wait functions. On my 2GHz PC, I've been using the value of 100 iterations, which allowed me to easily catch several asynchronous preemptions. You should be careful not to go overboard with this parameter, though, because you can overload the CPU, or more scientifically stated, you can create an unschedulable set of tasks. In this case, QF will eventually overflow an event queue and assert.

With all this scaffolding, you actually have a chance to observe an interesting asynchronous preemption, such as the instance shown in Figure 10.9(1). You need to run the DPP application (with the command-line parameter of 100 or so). As explained before, you will never get asynchronous preemptions unless you start typing on the keyboard. When the keyboard interrupt happens to come close enough after the clock tick, it might just manage to preempt one of the philosopher tasks. The keyboard ISR always posts an event to the Table object, and because Table has the highest priority in the system, upon the exit from ISR_kbd(), QK performs an asynchronous context switch to the Table active object. When this happens, you'll see that the preemption counter for one of the Philosopher tasks will increment on the screen (see Figure 10.10).

Figure 10.10. DPP application with QK running in a DOS console.

If you want to examine an asynchronous preemption closer, you can use the debugger built into the Turbo C++ IDE. You load the project DPP-DBG.PRJ (located in <qp>qpcexamples80x86qk cpp101ldpp) into the IDE and open the file qk_ext.c that I have specifically added to this project, even though it is already included in the qk.lib library. You set a breakpoint inside QK_scheduleExt_() indicated as label (1) in Figure 10.11 (see also Listing 10.12(9)). Next, select Run | Arguments… to define a command-line argument around 100. Now you can run the program. When you start typing on the keyboard, eventually you should hit the breakpoint (asynchronous preemption). You can step through the code from there. Figure 10.11 shows an example of my debug session.

Figure 10.11. Asynchronous preemption examined in the Turbo C++ debugger.

To demonstrate the QK priority-ceiling mutex, I've extended the Philosopher active object to allow random think and eat timeouts for philosophers rather than fixed timeouts used in the basic implementation. To implement the feature, I use the pseudorandom number (PRN) generator provided in Turbo C++ 1.01 ( random()). This generator, like most PRN generators, is not reentrant because it must preserve its state from one call to the next. To prevent corruption of this internal state, I protect the generator with the QK mutex, as shown in Listing 10.13.

Note that I use the number of philosophers N_PHILO as the priority ceiling to lock the mutex. This ceiling corresponds to the highest-priority Philosopher active object that can access the PRN generator (Philosopher active objects have priorities 1..N_PHILO). Since the priority of the Table active object (N_PHILO + 1) is above the ceiling, the mutex does not affect Table, which is exactly what I wanted to achieve. Table does not use the resource (PRN generator in this case), so it should not be affected by the mutex.

In the QK port header file qk_port.h (Listing 10.12), you saw the two contexts of two hypothetical libraries lib1 and lib2, which need TLS support in the same way as Newlib does. The QK port implemented the switching of the two “impure pointers” in the macro QK_TLS (Listing 10.12(18)). At the application level, I need to add the contexts to the active objects and I need to inform QK where these TLS contexts are located. I also need to call the library functions so that they are shared among all Philosopher active objects. Listing 10.14 shows these steps.

Finally, I need to define the library functions lib1_test() and lib2_test() that actually use the “impure pointers.” Listing 10.15 shows the test code.

As discussed in Section 10.5.4, the 80x87 FPU context saving and restoring is handled automatically in the QK extended scheduler. At the application level, you need to include the per-thread FPU context in every active object, which is done in Listing 10.14(1). You also need to set the QK_FPU_FLAG for every task that uses the FPU (see Listing 10.14(7)). And finally, you must use the FPU to test it. Though Listing 10.15 perform a lot of floating-point operations, it is also important to use the correct compiler options to select the FPU. I've compiled both the QP libraries and the DPP applications with the –f287 option, which instructs the Turbo C++ compiler to generate FPU hardware instructions.