Finding a better way to manage multicore resources
Chris Main 7/26/2011 7:53 PM EDT
Chris Main of TenAsys suggests that a better way to manage inter-process communications (IPC) in multiprocessor designs is by the use of global object networking, so that an application can be dynamically distributed across one or several CPUs at load time. Enabling embedded systems to support real-time determinism and scalability of processing power can’t be an afterthought. These capabilities must be designed into the core of the software from its inception, and that’s where most operating software environments in use today fall short.
In the case of TenAsys’ INtime operating systems, support for scalable processing was designed-in when Intel first conceived a real-time software environment for its X86 processor family.
Our vision is that in the embedded market, people want to be able to run their real-time application tasks independently of one another so that they are not subject to scheduling loads of other tasks. There are performance and software reliability limitations to using a single task scheduler that must balance the functions of real-time control and other types of processing such as implementing the system’s human interface.
When Intel first entered the embedded computing market back in the late 1970s with its single board computer products, the boards’ Multibus-I system bus interfaces were designed with multi-master capability.
This was at a time when other buses assumed a single bus master with the remaining circuit cards in the system being slaves. In contrast, Multibus-I and its successor Multibus II allowed for many computing elements as well as many I/O elements. From the start, software that was developed for Multibus systems needed to allow multiple processors to interface with I/O.
Every master in a Multibus system had its own OS. Intel’s iRMX ran on some. Unix ran on some and Microsoft Windows ran on some. TenAsys extended the Intel vision in the ‘90s and 2000’s by exploiting PC-compatible software platforms to support building multi-OS systems with the companies’ INtime RTOS and Microsoft Windows.
A key question that affects application scalability and which must be answered in building multi-OS systems is how processes running on different operating systems should communicate.
One could use a standard interface, such as sockets, to support communication between processes, but starting with an existing application, more sockets interfaces would need to be added in order to scale the system to use different numbers of processing units.
Communications using sockets interfaces are also not deterministic — there are a lot of software layers between the applications, and it is impossible to predict exactly when a communication from one processor to another will be responded to. Hence this method has limited usability in embedded applications.
A better way to manage inter-process communications (IPC) is via a simpler method, with a hidden transport that can be changed at will. It can be a scheme involving shared memory or via networking, but the mechanism should be transparent to the user and applications always using the same interface, no matter what communication method is being used.
A good way to do this is via global object networking, an innovative concept that uses an application programming interface (API) in the operating system kernel. A global object network addresses the limitations of traditional IPC methods by providing a managed environment with built-in process initiation and discovery services, so that an application could be dynamically distributed across one or several CPUs at load time.
Using global object networking, processes requiring services of other processes are found automatically and their location recorded by a global object manager in each OS. The global object manager keeps track of the established IPC links.
If a targeted process and/or the communication links to the targeted processes should fail, the manager notifies an initiating process.
In addition, the local manager keeps the system clean by clearing up all records when the IPC links are no longer required by the initiating process. Because the global object network is integrated with the OS, its overheads are low, and it does not require the development of any custom software by the application developer.
It is deterministic and is substantially more efficient than traditional IPC interfaces, and using this method, application designers can decide how application threads should interact rather than allowing a single central scheduler to do it.
Avoiding the use of a central scheduler is also important for maintaining determinism in a scalable multicore system.
Most multicore systems today have a single scheduler that assigns tasks to the cores as they become available.
When an I/O device interrupt comes in, time is wasted while the scheduler identifies which processor is running the task that must handle the interrupt. A better way is to treat application threads as independent entities, assigning them to processors and I/O devices at load time and allowing them to communicate when they need to, without disturbing processes that are not involved.
Typically, the cost of software upgrades has been a factor that has delayed the adoption of new processor technologies, but implemented as described above, embedded applications can be hosted on processors with differing numbers of cores, or even across multiple processor platforms, without requiring changes to the software. This opens the door to OEMs that want to take maximum advantage of the new multicore processor technologies.
Chris Main is CTO and cofounder of TenAsys Corporation, where he has led development of the company’s virtualization technologies. He has worked in real-time systems starting with minicomputers and was involved in the iRMS group at Intel. He was on the original development team for INtime. He earned a graduate degree in Physics from York University and postgraduate degree in Education from Bath University.
———————————————————————–