Manage multiple processes and processors in a deterministic multicore design

Chris Main, TenAsys Corporation

February 22, 2012

Chris Main, TenAsys Corporation

Multicore solutions
Single system manager: The introduction of multicore processors made a big impact in the computing industry as a whole. However, the adoption of multicores in control-system applications has been a little slow for two reasons. The first and main reason is that OEMs have not been sure how to migrate applications that were optimized to run on a single processor onto a multicore processor platform without breaking them. And second, the industry has not produced a clear path to follow for migrating applications from single processor systems to multicores that enables OEMs to get the most out of multicore processors without requiring significant changes to the software.

In an effort to provide the easiest solution, multicore system managers were introduced (Figure 3). These are essentially operating systems with load schedulers that make decisions on how to load the FBs (applications) on the processor cores. Generally, the method used is SMP (symmetrical multiprocessing). Although this processor loading method has proved acceptable for non-real-time applications, it falls short of the requirements for real-time control systems. FBs scheduled under SMP aren't guaranteed to be totally unaffected by the operation of other FBs, and the system's I/Os are not partitioned and dedicated to the associated FBs.

Multi-system manager: A better approach is to go back to the fundamentals and use embedded virtualization techniques to run each FB on a separate core of a multicore platform, with allocated/ dedicated I/Os and memory management (Figure 4). With each core under the control of an individual system manager (RTOS), the system is essentially an AMP (asynchronous multi-processing) system.


Click on image to enlarge.
The missing bit in this implementation is ability for the FBs to communicate with each other. This can be added to the application layer or embedded within each system manager (RTOS). The former is easier to implement but difficult to make transparent to the developer. It's even harder to integrate with the application's priority level so that any inter-FB communication is managed as part of the prioritization of other tasks that are running.

A better method is to integrate the IPC mechanism into the RTOS (Figure 5) where it may be automatically handled by the RTOS priority scheduler. This enables programmers to refer to standard exchange objects--such as mailboxes, semaphores, and shared memory blocks--within their code to perform IPC between processor cores and across platforms. This embedded IPC methodology is so transparent that it allows FBs to be separated and distributed among available processors with minimal code changes.


Click on image to enlarge.
For this system to work reliably there must be a means for the FBs to know the state of other FBs on which they depend. This is done by adding a system-manager layer to the environment. This layer provides a means of signaling system events, such as the creation and deletion of interdependent processes. Both the IPC and the management layers are designed to be extended across multiple instances of the RTOS, thus making it easy to scale a system from one to many processors, be they on the same platform or even multiple platforms.