多核资源API (MRAPI) 规范V1.0

multicore

需积分: 10 84 浏览量更新于2024-07-16 收藏 635KB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"MRAPI_Version1000.pdf" MRAPI（Multicore Resource API）是一种应用程序接口，专为多核处理器设计，用于管理并优化在多核系统上的任务分配、资源调度以及通信。MRAPI Specification V1.0是The Multicore Association发布的一份文档，该协会是一家专注于推动多核技术发展的组织。此文档的版本为1.0，于2010年11月23日发布，其目的是为开发者提供一个标准的接口，以便在多核平台上进行高效且协调的编程。 MRAPI的核心目标是简化多核环境下的编程复杂性，它提供了一组标准化的函数和数据结构，使得软件开发者能够更好地控制和利用多核处理器的计算能力。通过MRAPI，开发者可以创建并管理线程、进程，以及分配和同步资源，从而实现更高效的并发执行。该API可能包括以下关键功能： 1. **线程和进程管理**：MRAPI提供了创建、销毁、同步和调度线程及进程的接口。这允许开发者将任务分解到不同的核心上，以实现并行处理。 2. **资源分配**：在多核系统中，有效分配内存、处理器资源和其他硬件资源对于性能至关重要。MRAPI可能包含用于分配和释放这些资源的函数。 3. **通信与同步**：MRAPI可能包含了同步原语，如锁、信号量和条件变量，以确保在多线程或多进程环境中的正确通信和数据一致性。 4. **性能监控**：为了优化代码，开发者可能需要了解各线程或进程的运行情况。MRAPI可能提供性能计数器和监控工具，帮助开发者评估和调整程序性能。 5. **错误处理**：在多核环境中，错误管理和异常处理是必不可少的。MRAPI可能会提供一套机制来处理错误，确保程序的健壮性。 6. **移植性**：作为标准API，MRAPI旨在跨不同多核平台提供一致的接口，简化了代码在不同硬件上的移植。 MRAPI的使用有助于提高多核系统的整体性能，减少资源浪费，并降低开发多核应用的难度。然而，开发者在使用时仍需谨慎，因为不恰当的资源管理和调度可能导致性能下降或出现竞态条件等并发问题。此外，尊重版权和知识产权，未经许可不得复制、传输或翻译MRAPI文档，这是对知识产权的尊重和保护。

资源详情

资源推荐

MRAPI API Specification V1.0

The Multicore Association November 23, 2010 Page 16 of 158

locking. Mutexes are intended to support very fast, close-to-the-hardware implementations, whereas

semaphores and reader/writer locks provide more flexibility to the application programmer at the

expense of some performance.

All of the synchronization primitives are supported across MRAPI domains by default, but this may have

a performance impact (e.g., chip-to-chip synchronization will necessarily be slower). Sharing across

domains can be disabled by setting the MRAPI_DOMAIN_SHARED attribute of a synchronization primitive

to MRAPI_FALSE (default is MRAPI_TRUE).

2.3.1 Mutexes

MRAPI mutexes are binary, they support recursion (but that is not the default), and they are intended to

be the closest match to underlying hardware acceleration in many systems. Recursive locking is allowed

if the locking node already owns the lock, and if the mutex attributes have been set up to allow

recursion. Recursive locking means that once a mutex is locked, it can be locked again by the lock

owner before unlock is called. For each lock, a unique lock key is returned. This lock key must be

provided when the mutex is unlocked. The implementation uses the keys to match the order of the lock

and unlock calls.

Individual mutex attributes may vary, but they must be set before mutex creation, and they cannot be

altered later.

2.3.2 Semaphores

Semaphores, unlike mutexes, support counting locks. Therefore semaphores are differentiable in terms

of performance and other features–mutexes are binary, and some hardware has hardware acceleration

for this, whereas semaphores have richer functionally but may have slower performance.

2.3.3 Reader/Writer Locks

The MRAPI reader and writer locks provide a convenient mechanism for optimized access to critical

sections of code that are not always intended to modify shared data. These primitives support multiple

read-only accessors at any given time, or one exclusive accessor. This supports the Reader/Writer

Locks (RWL) software pattern that is commonly used for cases where there are more readers than

writers. In order to guarantee fairness, MRAPI implementations must enforce serialization of requests,

such that that no new read lock will be granted while a blocked write lock request is pending.

2.4 Memory

MRAPI supports two different notions of memory: shared memory and remote memory. Shared memory

is provided in MRAPI to support applications that are deployed on hardware which has physically

shared memory with hardware-managed cache coherency (coherent shared memory), but which cannot

rely on a single operating system to provide a coherent shared-memory allocation facility. Implementing

this can be hard, and discussions are ongoing with the MCA Hypervisor working group to understand a

potential relationship for supporting coherent shared memory. Remote memory is provided for systems

that require the use of explicit CPU, DMA, or other non-CPU mechanisms to move data between

memory subsystems, or which do not support hardware-managed cache coherency. The MRAPI

specification allows for implementations to support only those types of MRAPI memory that are feasible

for a given system, but the implementation must provide all API entry points and indicate via error

reporting that a given request cannot be satisfied.

2.4.1 Shared Memory

The functionality provided by the MRAPI shared memory API is similar to that of POSIX shared

memory, but MRAPI extends the functionality beyond the scope of a single operating system. It provides

MRAPI API Specification V1.0

The Multicore Association November 23, 2010 Page 17 of 158

the ability to manage the access to physically coherent shared memory between heterogeneous threads

of execution that may be on different operating systems and different types of cores.

2.4.2 Remote Memory

Modern heterogeneous multicore systems often contain multiple memory spaces, where data is moved

between memory spaces via non-CPU mechanisms such as direct memory access (DMA). One

example is the Cell Broadband Engine processor: the Power Processor Element (PPE) is a standard

Power Architecture™ core connected to main memory, but the processor also contains eight Synergistic

Processor Elements (SPEs) each of which has a small local store. Data must be copied to and from

SPE local stores via explicit DMA operations.

Remote memory might be implemented in many different ways, depending on the underlying hardware.

Sometimes actual copying (i.e., read or write operations) are needed, sometimes just software initiated

cache operations are needed (i.e., invalidate or flush). However, the purpose of an API should be to

hide these differences in order to enable portable and hardware independent software. So, in order to

access data, an API call should be made that might cause either a "read" and "sync", or some

combination (depending on the underlying hardware). The user should not need to care. The software

layer that constitutes the API should make sure the necessary operations are performed.

From the point of view of a given processing element, remote memory is memory that cannot be

accessed via standard load and store operations. For example, host memory is remote to a GPU core;

the local store of a Cell SPE is remote to the other SPEs or the PPE.

MRAPI offers a set of API functions for manipulating remote memory. Like MRAPI shared memory, the

API provides functions for creating, initializing, and attaching to remote memory. Unlike MRAPI shared

memory, the API provides functions for reading from and writing to remote memory.

The API does not place restrictions on the mechanism used for data transfer. However, catering to the

common case where it is desirable to overlap data movement with computation, the API provides non-

blocking read and write functions. In addition, flush and sync primitives are provided to allow support for

software-managed caches. The API read and write functions also support scatter/gather accesses.

For MRAPI users and implementers concerned about performance of the flush and synch functions, the

MRAPI working group recommends use of multiple memory regions; the implementation of the flush

routine should have the semantics of "anything that is dirty should be pushed back to memory", versus

“everything should be pushed back to memory”.

MRAPI API Specification V1.0

The Multicore Association November 23, 2010 Page 19 of 158

Remote accesses (reads or writes) always result in a copy and must use MRAPI calls. Implementations

may define multiple access types (depending on underlying silicon capabilities), but must provide

MRAPI_RMEM_ATYPE_DEFAULT, which has strict semantics and is guaranteed to work.

2.5 Metadata

MRAPI provides a set of API calls designed to allow access to information regarding the underlying

hardware context an application is running on. These capabilities are described in the following

sections.

2.5.1 Metadata Resource Data Structure

A call to mrapi_resources_get() returns a data structure of type mrapi_resource_t, see Section

2.11.4. This data structure is provided in the form of a tree co

ntaining the set of resources that are

visible to the calling MRAPI node. Each node in the tree represents a resource in the system, and each

node contains attributes that provide additional information about a given resource. The resource tree

may be optionally filtered by the subsystem_filter input parameter. Examples of such filters include

CPU, cache, and hardware accelerators. An MRAPI implementation must define what filters it can

provide as an enumerated type.

The resource data structure can contain hierarchical nodes in addition to the resource nodes

themselves. For example, the concept of a core complex, which could contain multiple cores, would be

represented as a parent node to the core nodes in the resource tree.

During initialization MRAPI may read in the system resources from a data file which may have a tree

structure, such as XML or a device tree, so it is convenient to represent the resource data structure as a

tree. Alternatively, the resources could be statically compiled into the MRAPI implementation.

See Section 5.1 for a use case and example code for getting and navigating a resource tree.

2.6 Attributes

Attributes are provided as a means of extension for the API. Different implementations may define and

support additional attributes beyond those pre-defined by the API. In order to promote portability and

implementation flexibility, attributes are maintained in an opaque data structure that may not be directly

examined by the user. Each resource (e.g., mutex, semaphore) has an attributes data structure

associated with it, and many attributes have a small set of predefined values that must be supported by

MRAPI implementations The user may initialize, get, and set these attributes.

If the user wants default behavior, the intention is that they should not have to call the initialize, get, and

set attribute functions. However, if the user wants non-default behavior, the sequence of events should

be as follows:

1. mrapi_<resource>_init_attributes(): Returns an attributes structure with all attributes

set to their default values.

2. mrapi_<resource>_set_attribute() (Repeat for all attributes to be set): Sets the given

attribute in the attributes structure parameter to the given value.

3. mrapi_<resource>_create(): Passes the attributes structure modified in the previous step

as a parameter to this function.

After a resource has been created, its attributes may not be changed.

At any time, the user can call mrapi_<resource>_get_attribute() to query the value of an

attribute.

MRAPI API Specification V1.0

The Multicore Association November 23, 2010 Page 20 of 158

For a use case in which attributes are customized, see section: 5.1.

2.7 Sharing Across Domains

By default, most of the MRAPI primitives are shared across MRAPI domains (Section 2.1).

Implementations may suffer a performance impact for resources that are shared across domains.

The following MRAPI primitives are shared across domains by default: mutexes, semaphores,

reader/writer locks, and remote memory. For any of these primitives, you can disable sharing across

domains by setting the MRAPI_DOMAIN_SHARED attribute to MRAPI_FALSE and passing it to the

corresponding *_create() function.

For the remaining primitive–MRAPI shared memory–the determination of which nodes it can be shared

with (regardless of their domains) is specified in the nodes list that is passed in when the shared

memory is created.

2.8 Waiting for Non-Blocking Operations

The API has blocking, non-blocking, and single-attempt blocking variants for many functions. The non-

blocking variants have “_i” appended to the function name to indicate that the function call will return

immediately but the requested transaction will complete in a non-blocking manner. The single-attempt

blocking functions will have the word "try" in the function name (for example, mrapi_mutex_trylock).

Remote memory is the only resource that supports non-blocking variants (for reads/writes).

The non-blocking versions fill in an mrapi_request_t object and return control to the user before the

requested operation is completed. The user can then use the mrapi_test(), mrapi_wait(), and

mrapi_wait_any() functions to query the status of the non-blocking operation. The mrapi_test()

function is non-blocking whereas the mrapi_wait() and mrapi_wait_any() functions will block

until the requested operation completes or a timeout occurs.

Some blocking functions may have to wait for system events–e.g. buffer allocation or for data to arrive–

and the duration of the blocking will be arbitrarily long (and may be infinite), whereas other blocking

functions do not need to wait for system events and can always complete in a timely fashion, with a

success or failure. Single-attempt blocking functions that complete in this timely fashion include

mrapi_mutex_trylock(), mrapi_sem_trylock(), mrapi_rwl_trylock().

If a buffer of data is passed to a non-blocking operation (for example, to mrapi_rmem_write_i())

that buffer may not be accessed by the user application for the duration of the non-blocking operation.

That is, after a buffer has been passed to a non-blocking operation, the program may not read or write

the buffer until mrapi_test(), mrapi_wait(), or mrapi_wait_any() have indicated completion,

or until mrapi_cancel() has canceled the operation.

2.9 Error Handling Philosophy

Error handling is a fundamental part of the MRAPI specification. However, some accommodations have

been made to support trading-off completeness for efficiency of implementation. For example, some API

functions allow implementations to optionally handle errors. Consistency and efficient coding styles also

govern the design of the error handling. In general, function calls include an error code parameter used

by the API function to indicate detailed status. In addition, the return values of several API functions

indicate success or failure, which enables efficient coding practice. A parameter of type

mrapi_status_t will encode success or failure states of API calls. MRAPI_NULL is a valid return

value for mrapi_status_t; it can be used for implementation optimization.

剩余157页未读，继续阅读

etc9527

粉丝: 474
资源: 16

多核资源API (MRAPI) 规范V1.0

mrapi:快速开发API或DAL应用程序的框架

EmbeddedWebBrowser_FS_Version 14.70.0〖含全部源码和DEMO，支持D5-XE2〗

LSSVR_version4.LSSVR

以下哪列选项是获取PHP版本的常量（ ） （2 分） A．__ FILE __ B．__ LINE __ C．PHP_VERSION D．PHP_OS

checking for OpenSSL_version... no

UPDATE `ipd_project_version`.`t_version_sync_record` sync JOIN `ipd_project_version`.`t_version_plan` version ON sync.plan_master_id = version.master_id WHERE sync.id IN ( SELECT id FROM `ipd_project_version`.`t_version_sync_record` ss WHERE ss.number IS NULL );

tar -zcvf out_release/${EXTERNAL_VERSION}.tar.gz -C out/target/product/cancun/cp_sign/QOGIRL6_SIGN .

..\hallib\Src\stm32f1xx_ll_sdmmc.c: 0 warnings, 1 error compiling stm32f1xx_ll_utils.c... ..\core\core_cm3.h(63): error: #5: cannot open source input file "cmsis_version.h": No such file or directory #include "cmsis_version.h"

from LSSVR_version4.LSSVR import LSSVMRegression

__version__ = __version_info__.__version__

Can't read version file: ls-version_.py. Fall back to: version_.py

#include "cmsis_version.h" ..\SYSTEM\delay\delay.c: 0 warnings, 1 error compiling stm32f1xx_ll_usb.c... ..\core\core_cm3.h(63): error: #5: cannot open source input file "cmsis_version.h": No such file or directory

ffmpeg_version.cmake 缺少

The "background.persistent" key cannot be used with manifest_version 3. Use the "background.service_worker" key instead.

Unknown CMake command "write_basic_packMyLibConfigage_version_file".

2进制3位数过去现在将来输赢公式代码.txt

最新资源

以下哪列选项是获取PHP版本的常量（）（2 分） A． FILE B． LINE C．PHP_VERSION D．PHP_OS

version = __version_info.version__