Questions and Answers from the Webinar
Q: Can you elaborate on how hardware accelerators will interact with
embedded processors using MRAPI®? An API is a library of C/C++ functions,
but it is not clear how an API can be used with a hardware accelerator,
which can be very application specific.
A: The API can be implemented on top of a hardware accelerator. For
example, an SoC may have hardware acceleration for mutexes, in which case an
MRAPI® implementation could utilize that hardware accelerator without the
programmer needing to know how to interact with it directly. Alternatively,
if you want to cooperatively manage access to hardware accelerators, such as
an MPEG encoder, your application would create an MRAPI® mutex and use locks
on that mutex to govern when application threads could access the encoder.
MRAPI® does not attempt to manage the resources directly as this capability
belongs to the operating system or hypervisor code.
Q: Does the MRAPI® have test cases?
A: MRAPI® itself does not have test cases. However, as with the MCAPI®
example implementation which is available from the Multicore Association,
ultimately we should have an MRAPI® example implementation that will contain
Q: Do you have implementations of MRAPI® that can be tested by the
A: We hope to publish a simple POSIX implementation along with the release
of the spec.
Q: I assume MRAPI® relies upon a "local" resource manager? In other words,
MRAPI® must store state, and so does it need a way to allocate state storage?
A: It depends on the specific MRAPI® implementation as to how resources are
managed. Our initial implementation stores state in shared memory protected
with a semaphore.
Q: I saw a statement that other solutions are too heavyweight because they
target distributed systems. Does this 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 as a distributed system?
A: To be clear, MRAPI® targets cores on a chip and chips on a board. MRAPI® is
not intended to scale beyond that scope.
Q: Is it possible to hide the differences between local and remote memory by
just the different properties of these memories? Remote memory will have
higher latency, some access restrictions, etc.
A: The working group has considered the possibility of allowing the "promotion" of local memory to remote memory, and then allowing all memory
accesses to occur through the API. This would effectively hide the
difference, but at a performance cost. For now this is a deferred feature.
Q: In many hardware 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 are you planning to handle the
A: In the situation where the application does not want to be disturbed by
frequent callbacks, then it would be better for the application to
periodically poll MRAPI® at a time of its own choosing. This is certainly
possible with MRAPI®.
Q: What is the idea to handle MRAPI® asking for HW accelerators if these
accelerators are actually powered off because of inactivity?
A: First, keep in mind that a primary goal of MRAPI® is to provide primitive
services that higher layer pieces of hardware or software can utilize. In
other words, MRAPI® contains the primitives for high level resource sharing.
Features such as power management require more functionality than what MRAPI®
was intended to provide (to maintain efficiency). So, in such a scenario
requiring power management, the application would determine that there was
no acceleration available and would have to find an alternative means to
perform its work, perhaps by executing code on the CPU.
Q: Are there any plans to include trigger APIs? For example, invoke callback
when a particular resource hits some pre-defined conditions/threshold?
A: Currently there are no threshold-related callbacks other than counter
wrap-arounds. MRAPI® may consider this for a future version.
Q: For primitives, did the MRAPI® working group consider including
read-copy-update locks (RCUs)?
A: The MRAPI® working group did consider read copy update locks. After
discussion with some of the original creators of the RCU code for Linux, we
determined that for now there is not sufficient evidence that a high
performance user-level implementation of RCU was feasible. We intend to
monitor developments in this area as we are aware that it is an active area
Q: The specified MRAPI® primitives are necessary, but seem to be
insufficient. I would think that the goal of MRAPI® would be to include the
ability to write a resource manager that any application that uses MRAPI®
could plug into. That implies that at a minimum: resource enumerations
should be standardized, or a mechanism for self-describing enumerations be
A: MRAPI® is intended to provide some of the primitives that could be used
for creating a higher level resource manager. However, it is also intended
to be useful for application level programmers to write multicore code, and
for this reason it was kept minimal and orthogonal to other Multicore
Association APIs. The working group believes that a full-featured resource
manager would require all of the Multicore Association APIs, e.g., MCAPI®,
MRAPI®, and MTAPI.
Q: Are any companies currently incorporating or have plans to incorporate
MRAPI® in their products. If so, can you name the products?
A: At this time there have been no public announcements. There is at least
one university research project that is looking at MRAPI® for heterogeneous
multicore computing. We expect more activities to emerge once the spec is
Q: Is MRAPI® planned to be processor agnostic?
A: Yes, that is the plan.
Q: Is MRAPI® dependent on any other Resource Management standards and/or
A: No, there should be no such dependencies in MRAPI®.