MULTICORE RESOURCE MANAGEMENT API WORKING GROUP (MRAPI®)
Objective
MRAPI® is an industry-standard API that specifies essential application-level resource management capabilities. Multicore applications require this API to allow coordinated concurrent access to system resources in situations where:
- There are not enough resources to dedicate to individual tasks or processers, and/or
- The runtime system does not provide a uniformly accessible mechanism for coordinating resource sharing.
This API is applicable to both SMP and AMP embedded multicore implementations (whereby AMP refers to heterogeneous both in terms of software and hardware). MRAPI® (in conjunction with other Multicore Association® APIs) can serve as a valuable tool for implementing applications, as well as for implementing such full-featured resource managers and other types of layered services.
Overview
Multicore Resource Management API (MRAPI®) captures the essential capabilities required for managing shared resources in a closely distributed embedded system. These resources include multiple, homogeneous or heterogeneous cores or chips, hardware accelerators, memory regions, and I/O. MRAPI® supports the ability to declare and allocate/destroy shared memory regions and to identify nodes which have access to each region. MRAPI® also provides application-level synchronization primitives for coordinating access to shared resources. MRAPI supports queries regarding static and dynamic resources, and it supports system-level event notification such as power-savings states, device failures, and hypervisor repartitioning. It allows coordinated concurrent access to system resources in situations where (a) there are too few resources to dedicate to individual tasks or processors, and/or (b) the runtime system does not provide a uniformly accessible mechanism for coordinating resource-sharing.
MRAPI® is scalable and can support virtually any number of cores, each with a different processing architecture and each running the same or a different operating system, or no OS at all. As such, MRAPI® is intended to provide source-code compatibility that allows applications to be ported from one operating environment to another.
Chairpersons
- Jim Holt, Manager, Processor Core Architecture, Freescale Semiconductor
- Sven Brehmer, President, PolyCore Software
Frequently Asked Questions
- How will hardware accelerators interact with embedded processors using MRAPI? Since an API is a library of C/C++ functions, it is not clear how an API can be used with a hardware accelerator, which can be very application specific.
- How does this API ask for HW accelerators if these accelerators are actually powered off because of inactivity?
- Does MRAPI rely upon a 'local' resource manager? That is, does MRAPI store state and need a way to allocate state storage?
- I saw a statement that other solutions are too heavyweight because they target distributed systems. Does it mean that your goal is not to target the distributed system? What happens when we have a multi-chip multi-core? Isn't this the same distribute
- Is it possible to hide the differences between local and remote memory by just different properties of these memories? Remote memory will have higher latency, some access restrictions, etc.
- In many HW systems, transitions between low power (or no power) and fully working conditions are extremely frequent. In such systems some state change callbacks will become a nightmare. How does MRAPI handle the situation?
- Are there any plans to include trigger APIs? For example, invoke callback when a particular resource hits some pre-defined conditions/threshold?
- Primitives - did you consider including read-copy-update (RCUs)?
- These primitives included in MRAPI are necessary, but seem to be insufficient. Shouldn
- Are any companies currently incorporating or have plans to incorporate MRAPI in their products. If so, can you name the products?
