Designed for Multicore: Enea Message Passing Model

Marcus Hjortsberg, VP of Product Management at Enea explains how the Enea message passing programing model was designed for multicore long before multicore was a emerging trend. 

RTOS Basics 2: RTOS vs. GPOS

REALTIME OS VS. GENERAL PURPOSE OS

Many non-real-time operating systems also provide similar kernel services. The key difference between general-computing operating systems and real-time operating systems is the need for "deterministic” timing behavior in the real-time operating systems.

 

Formally, "deterministic” timing means that operating system services consume only known and expected amounts of time. In theory, these service times could be expressed as mathematical formulas. These formulas must be strictly algebraic and not include any random timing components. Random elements in service times could cause random delays in application software and could then make the application randomly miss real-time deadlines – a scenario clearly unacceptable for a real-time embedded system.

 

General-computing non-real-time operating systems are often quite non-deterministic. Their services can inject random delays into application software and thus cause slow responsiveness of an application at unexpected times. If you ask the developer of a non-real-time operating system for the algebraic formula describing the timing behavior of one of its services (such as sending a message from task to task), you will invariably not get an algebraic formula. Instead the developer of the non-real-time operating system (such as Windows, UNIX or Linux) will just give you a puzzled look. Deterministic timing behavior was simply not a design goal for these general-computing operating systems. On the other hand, real-time operating systems often go a step beyond basic determinism. For most kernel services, these operating systems offer constant load-independent timing: In other words, the algebraic formula is as simple as: T(message_send)= constant, irrespective of the length of the message to be sent, or other factors such as the numbers of tasks and queues and messages being managed by the RTOS.

 

While general-computing operating systems often offer non-deterministic services in these areas, fully deterministic solutions have been described in this paper.  Timing determinism is of critical importance in real-time embedded applications such as communication systems, mobile baseband radios, airborne computers, medical instruments and automotive systems.

Enea Whitepaper

 

 

The awarded-winning Enea OSE Multicore Edition offers bare metal performance with a simple programming model.  Learn More. 

RTOS Basics: Inside the Kernel

The "kernel” of a real-time operating system ("RTOS”) provides an "abstraction layer” that hides from application software the hardware details of the processor (or set of processors) upon which the application software will run. In doing so, it supplies five main categories of basic services to application software. The most basic category of kernel services is task management. This set of services allows application software developers to design their software as a number of separate "chunks” of software – each handling a distinct topic, a distinct goal, and perhaps its own real-time deadline. Each separate "chunk” of software is called a "task”. Services in this category include the ability to launch tasks and assign priorities to them. The main RTOS service in this category is the scheduling of tasks as the embedded system is in operation. The task scheduler controls the execution of application software tasks, and can make them run in a very timely and responsive fashion.  

The second category of kernel services is intertask communication and synchronization. These services make it possible for tasks to pass information from one to an-other, without danger of that information ever being damaged. They also make it possible for tasks to coordinate, so that they can productively cooperate with one another. Without the help of these RTOS services, tasks might well communicate corrupted information or otherwise interfere with each other. Since many embedded systems have stringent timing requirements, most RTOS kernels also provide some basic timer services, such as task delays and time-outs.

 

Many (but not all) RTOS kernels provide dynamic memory allocation services. This category of services allows tasks to "borrow” chunks of RAM memory for temporary use in application software. Often these chunks of memory are then passed from task to task, as a means of quickly communicating large amounts of data between tasks. Some very small RTOS kernels that are intended for tightly memory-limited environments, do not offer dynamic memory allocation services. Many (but not all) RTOS kernels also provide a "device I/O supervisor” category of services. These services, if available, provide a uniform framework for organizing and accessing the many hardware device drivers that are typical of an embedded system. 

In addition to kernel services, many RTOSs offer a number of optional add-on operating system components for such high-level services as file system organization, network communication, network management, database management, user-inter-face graphics, etc. Although many of these add-on components are much larger and much more complex than the RTOS kernel, they rely on the presence of the RTOS kernel and take advantage of its basic services. Each of these add-on components is included in an embedded system only if its services are needed for implementing the embedded application, in order to keep program memory consumption to a minimum.

 

Enea Whitepaper

 

Enea OSE is perfect to Telecom
learn more here.

Leading Multicore Processing Models: Advantages and Disadvantages

There are fundamentally three multiprocessing models that are used to describe system designs on multicore devices; the SMP, AMP and the bare metal model. These models have a number of benefits and drawbacks, which will be briefly described below

The SMP Model
The Symmetric Multi Processing model is the model used in the design of several enterprise OSs such as Linux as well as in the design of its application domain. In such OSs and their applications data is to a large extent shared, and a number of different locking mechanisms and atomic operations are used frequently for synchronization. 

 

The SMP model is easy to manage from a SW management perspective since it creates a good abstraction where the OS facilitates best-effort cpu load balancing, and it has been used in the server and desktop application domain for a very long time. Enterprise OSs like Linux and Windows provides a best-effort execution platform for these kinds of CPU-intensive applications.The high degree of hardware resource abstraction is in many cases an advantage, but the layer introduces substantial overhead when the application becomes as I/O intensive as they tend to be in embedded packet forwarding/routing applications. The principles of the shared memory programming model on the application level and inside the Linux kernel is based on using mutable shared objects in memory, and this is an inherent bottleneck to scalability in Multicore systems. This will inevitably lead to poor scaling to many cores.This, together with the fact that the complex SMP implementation of kernels in many cases has the drawback of not being deterministic, makes the classic SMP OSs less suitable as a RTOS for high-speed packet processing in the long run.

The AMP Model
The Asymmetric Multi Processing model uses an approach where each core is running its own complete, isolated, operating system or application frame-work (an alternative term for a more light-weight RTOS). This leaves the door open to also choose to have different RTOSs on different cores. The advantage of an AMP system is that high-performance is achieved locally and that it scales well to several cores. Using theAMP model and virtualization technique is also a way to being able to reuse legacy single core designs.The drawback with the AMP model is that the OS provides no support to the distributed application for load balancing or OS resource management.  The configuration, load and startup of such an application is also inherently complex to design.

”Bare Metal” Model
The ”bare metal” model is a single threaded execution model where the available APIs are processor-vendor specific. Since no regular RTOS exist for these threads, a common approach is to run a regular operating system on one or several cores, like Linux, and let the rest of the cores execute a “bare metal” thread and use an application framework that creates an abstraction of the hardware layer. The advantage here is of course that maximal performance and minimal overhead is achieved when running without an RTOS, but the disadvantage is though that the software becomes hardware-specific, which will force a redesign of any applications whenever the hardware is upgraded. Also, the parts of the system running without an RTOS or application framework will take on the role of a black box, i.e. there will be no observability except for the external interfaces.  Any support for tracing, debug or post mortem dump support is not available, and therefore the amount of code “out there” must therefore naturally be kept to a minimum. Over the time though, the need for more functionality in these parts will most likely grow which in turn increases the need for better device abstraction.

Conclusion
Given the advantages and disadvantages of these models - it there a way to approach multicore design that blends the advantages of these methods? 

Enea Whitepaper

 

Enea has a solution to this dilema, you can learn more in this white paper.