The Multicore Association®
Multicore Association Appearance
On September 16-17 (hey, that's this week), the Multicore Association will
be exhibiting at and sponsoring the inaugural Linley Tech Processor
Conference in San Jose. Be sure to come by our booth to meet MCA president,
MRAPI® Webinar Update
A few weeks ago, we had a live webinar about our Multicore Resource
Management API, featuring Jim Holt (chairman of the MRAPI® working group).
That webinar is now available for download from our website. Whether you
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
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 testcases.
Q: Do you have implementations of MRAPI® that can be tested by the specification reviewers?
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?
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 situation?
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.
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 created.
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
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 approaches?
A: No, there should be no such dependencies in MRAPI®.
If you do not wish to receive e-mail from The Multicore Association®, you can un-subscribe. MCA sends no more than one e-mail per month to registered users at www.multicore-association.org. Continuing your subscription ensures you'll be notified when events and other important announcements are available.