Parallel API for embedded systems goes public
The Multicore Association has published a specification for a programming interface that aims to simplify the job of building applications that can not only use many cores running in parallel but schedule jobs dynamically depending on which types of core are available.
Urs Gleim, chair of the MTAPI group and head of the research group at Siemens parallel systems operation in Germany, said there is a clear for a multicore-programming API and pointed to the company as an example. “All these business units have the problem of moving from single core multicore products now. We are aligning these activities inside the company and trying to leverage synergies where it’s possible.
“We had the idea to implement a task API that could be reused across products, and not reinvent the wheel at each business unit. We found that the Multicore Association has exactly the same goals. TI and Freescale already had implementations and we found that the requirements for creating an API are very similar across companies,” said Gleim. It made more sense to adopt an industry standard than simply implement one used by a single, albeit very large company.
MTAPI is designed to simplify for the application programmer parallel programming at the task level. “Break down a chunk of work into smaller taksks that can then be executed in parallel,” said Gleim.
“What you want to support are thousands of lightweight tasks and give the programmer the ability to break down the application into little portions of code that are independent of each other,” said Gleim.
In the context of MTAPI, a task is roughly analogous to a worker thread in conventional systems. However, MTAPI uses a tiered approach to improve flexibility. A task, which runs to completion at each invocation, calls on jobs to handle its workload. Each job can be broken down into actions that are called independently. This allows for situations where the workload of a task can be handled in part by dedicated hardware and by a variety of different processors.
Today’s operating systems offer a thread model that requires a lot of low-level synchronization. “MTAPI takes away a lot of this complexity. It’s different from the low-level constructs used today,” said Gleim.
“MTAPI is a C API and pure library, unlike OpenCL or Cilk, where you have language extensions. For a lot of companies it’s not easy to change the build process. We can’t just change the compiler to something else or other things won’t work anymore,” Gleim explained. “The goal was to find the shortest syntax: a tradeoff between ease of use and a certain amount of configurability.”
MTAPI applications can use a scheduler to allocate jobs and actions dynamically if code has been written that will target different types of core. For example, an action might perform a Turbo decode that normally runs on dedicated hardware. But if the scheduler – which can be customized to the system – determines that the hardware unit is not available, this operation could be sent to a software-only action that runs on a DSP.
“You have the ability to get information about the implementation. You can get properties of the implementation and then it would be possible to return attributes of the scheduler. You can influence the scheduler by setting attributes to tasks. You define actions as having an affinity to certain cores, for example,” said Gleim.
MTAPI is designed for applications where there is limited interprocessor communication – the worker threads are largely expected to handle discrete pieces of work. “The idea is that the synchronization is at the task level. You start a task and wait for it to finish and where possible you copy data elements into the task that processes them,” said Gleim.
If tasks do need to communicate they can use other protocols such as the association’s own MCAPI. “The idea was that the APIs go hand in hand with MCAPI for shared-data accesses.”
One issue for any standard organization is whether customers aim to use their offerings in implementations.
“We are finally at the point where we are seeing more visible traction,” said Markus Levy, president of the Multicore Association, although it has been difficult to point to instances of the group’s standards being used because few have opted to declare their use publicly.
Gleim said the hope is that tools vendors will take the MTAPI, which is still a relatively low-level interface, and build libraries and other tools on top to help automate the development of parallelized applications. “We want to buy things like operating systems. We use more and more tools in the context of multicore programming, such as correctness and test checkers. The problem today is that the tools have a dependency on the synchronization APIs. The benefit of MTAPI is that tools will know about it.”
