On Time Logo
Home Search Site Map Contact

On Time RTOS-32 Documentation

Welcome

RTTarget-32

RTKernel-32

RTKernel-32 Programming Manual

Introduction

Multitasking, Real-Time, and RTKernel-32

Module RTKernel-32

Alternate APIs for RTKernel-32

Supplemental Modules

RTKernel-32 Drivers

Demo Programs

Advanced Topics

RTKernel-32's Debug Version

How to Create Threads

Interrupt Handling

Avoid Polling

Preemptive or Cooperative Multitasking?

Waiting for Several Events

Avoid Large Message Types

Mutual Exclusion

Avoid Time Slicing

Cyclic Tasks (Timer)

Priorities

Starting Objects' Methods as Tasks

Performance and Interrupt Response Times

Multiprocessor Applications

OpenMP

Task Switches in Cooperative Scheduling

Writing Custom Kernel Drivers

Using the FPU in Interrupt Handlers

Typical Error Sources

Error and Information Messages

RTKernel-32 Reference Manual

RTFiles-32

RTIP-32

RTPEG-32

RTUSB-32
PreviousPrevious NextNext

Multiprocessor Applications

Multiprocessor applications are not much different from single-CPU programs. Instead of linking the single-processor kernel Rtk32.lib or Rtk32s.lib, multiprocessor applications should link Rtk32mp.lib (Debug Version) or Rtk32mps.lib (Standard Version). By default, RTKConfig flags RF_PREEMPTIVE and driver flag DF_IDLE_HALT are set in the multiprocessor kernel.

The High Resolution Timer driver CLKHRTPC in Drvrt32.lib must be replaced because it does not support APIC mode. It is recommended to use the combination CLKAPIC with HRTPENT, HRTHPET, or HRTPM.

Example:

Rtk32mp.lib Clkapic.lib Hrtpent.lib Fltpii.lib Drvrt32.lib Rtt32.lib

The multiprocessor kernel in Rtk32mp[s].lib supports between 1 and 32 CPUs. If RTTarget-32's multiprocessor management API reports that no additional CPUs are available, it will behave just like the single-processor kernel in library Rtk32[s].lib. The multiprocessor kernel can also be forced to ignore additional CPUs using RTKConfig flag RF_NO_MP. Driver flag DF_NO_HYPERTHREAD can be used to switch off Hyperthreading.

When more than one CPU is available, the multiprocessor kernel will start one Idle Task per CPU in RTKernelInit. The number of threads in task state TS_CURRENT is always equal to the number of CPUs. The scheduler will distribute tasks among the available CPUs according to the scheduling rules, dynamically moving tasks from one CPU to another, if required. Interrupt handlers may be executed on any CPU, even several in parallel.

Synchronization among tasks is implemented in the same way under the single- and multiprocessor kernel: all RTKernel-32 operations for semaphores, Win32 Critical Sections, mailboxes, message passing, and spinlocks are multiprocessor safe.

To synchronize data accesses by interrupt service routines and tasks, merely disabling interrupts (as done by most programs designed for single-processor targets) is not sufficient. Four approaches for mutual exclusion with ISRs are available:

  • Use Semaphores or Mailboxes Only. Interrupt handlers should be designed not to share global data with tasks. Rather, have the interrupt handlers send signals or messages though semaphores or mailboxes.
  • Use Atomic Operations. If the shared variable is just an integer such as a counter, use one of the interlocked operations of the Win32 API. Available functions are InterlockedCompareExchange, InterlockedDecrement, InterlockedExchange, InterlockedExchangeAdd, and InterlockedIncrement.
  • Modify Variables Only in Tasks or ISRs. Many interrupt handlers can be designed such that one set of variables is only written, and the other only read. A FIFO ring buffer, for example, can be implemented in this way.
  • Use Spinlocks. Spinlocks have similar semantics as semaphores, but they never cause a blocking task switch and are therefore suited for interrupt handlers. RTKernel-32's spinlocks guarantee FIFO access and offer maximum lock time statistics and kernel tracer entries as debugging aids. On the other hand, they require more memory than RTTarget-32 spinlocks. For resources with high congestion, RTKernel-32 spinlocks will perform better while RTTarget-32 "Fast" spinlocks will be a bit faster for resources with low congestion.

Cooperative Scheduling and Reentrace

Some applications use cooperative scheduling hoping to avoid all reentrance problems introduced by preemptions. In a multiprocessor environment, several tasks run at the same time so all shared resources must be properly protected, even with cooperative scheduling.

Hyperthreading

The multiprocessor kernel can also use Hyperthread virtual CPUs, if RTKConfig driver flag DF_NO_HYPERTHREAD has not been set. Since Hyperthread virtual CPUs share resources with the real CPU, a few issues must be considered.

While Hyperthreading can improve the total processing power of a CPU, it will usually degrade real-time performance. For example, if a program has two tasks, one with a high and one with a low priority, a single-processor system will run the higher priority task at 100% CPU load and the other task not at all. On a Hyperthreading system, both tasks would run at the same time, but since they share the same physical CPU, they would both run at about 60% of the speed they would run at alone. Thus, Hyperthreading slows down the high priority task by about 40%.

A Hyperthread virtual CPU does not know about RTKernel-32 priorities and low priority tasks can take away resources from high priority tasks. In particular, this is a problem with RTKernel-32's Idle Task. To prevent it from slowing down application tasks running on the same physical CPU, preemptions are enabled and RTKConfig driver flag DF_IDLE_HALT is set by default in the multiprocessor kernel. This will cause the Idle Tasks to go into the HALT CPU state, releasing all CPU resources to the other Hyperthread(s).

LeftAdvanced Topics

UpPerformance and Interrupt Response Times

DownOpenMP

Copyright © 1996,2022 On Time