DEENESPTFRRUARHIKOZHNL

estrutura ara::core::PoolOptions

[SWS_CORE_00026] Upstream: RS_AP_00130

struct PoolOptions {...};

Implementation of std::pmr::pool_options from [mem.poly.pool_options.class]

Header-Datei#include "ara/core/memory_resource.h"
Forwarding-Header#include "ara/core/core_fwd.h"
Scopenamespace ara::core

Guia do utilizadorGERADO POR IA

Configura limites de blocos e chunks para recursos de memória baseados em pool.
GERADO POR IA não revisado Modelo: gemini-3.8-flash-medium · Esforço: medium · Temperatura: não controlável · Prompt: 79719d3800dc Procedência Perguntas em aberto (3)
traduzido do guia alemãogemini-3.8-flash-low · 2026-10-13 · Original em alemão

Configura limites de blocos e chunks para recursos de memória baseados em pool.

A estrutura ara::core::PoolOptions destina-se à configuração de recursos de memória baseados em pool, de acordo com std::pmr::pool_options. Ela permite limitar a quantidade máxima de blocos por chunk por meio de max_blocks_per_chunk [SWS_CORE_00027], bem como definir o tamanho máximo de bloco do pool via largest_required_pool_block [SWS_CORE_00028]. Como agregado de dados simples, a estrutura é preenchida antes da inicialização do recurso de memória e passada ao seu construtor. Interpretação: como não há validação própria, os desenvolvedores devem garantir que os valores limites configurados não sobrecarreguem a memória física de trabalho. Pergunta (aberta)

Contexto

A estrutura de dados ara::core::PoolOptions disponibiliza parâmetros de configuração para recursos baseados em pool de memória no módulo core da AUTOSAR Adaptive Platform. Ela destina-se ao controle direcionado do comportamento de alocação e orienta-se pela funcionalidade padrão de C++ de std::pmr::pool_options. A estrutura é incluída por meio do cabeçalho <ara/core/memory_resource.h> e interage estreitamente com recursos de memória de pool, os quais mantêm chunks e blocos contíguos para requisições recorrentes de memória.

Em sistemas de tempo real e críticos para a segurança, a limitação e a previsibilidade das operações de memória dinâmica são essenciais. Nesse contexto, ara::core::PoolOptions assume o papel de um desacoplador entre os requisitos de capacidade específicos da aplicação e o gerenciamento interno dos pools de memória. Por meio da estrutura, os desenvolvedores podem definir quantos blocos, no máximo, podem ser agrupados dentro de um chunk [SWS_CORE_00027] e qual tamanho máximo de bloco ainda deve ser atendido por meio dos pools especializados [SWS_CORE_00028]. O software de aplicação que instancia recursos de memória utiliza essas opções para evitar a fragmentação excessiva e controlar os limites de alocação de forma determinística.

Ciclo de vida

Como um tipo simples de configuração (struct), ara::core::PoolOptions possui um ciclo de vida leve, sem transições complexas de estado interno. A criação ocorre tipicamente como um objeto local na pilha (stack) ou como uma constante estática de configuração antes da instanciação do recurso de memória correspondente. Na instanciação, ambos os atributos max_blocks_per_chunk [SWS_CORE_00027] e largest_required_pool_block [SWS_CORE_00028] são inicializados por padrão com o valor 0.

Interpretação: Um valor de 0 provavelmente deve sinalizar ao recurso de memória receptor que os limites padrão específicos da plataforma devem vigorar. Como se trata de um objeto de valor puro, ara::core::PoolOptions não possui recursos no sentido de RAII e não executa ações de limpeza na destruição. O ciclo de vida da estrutura é normalmente acoplado à fase de criação do recurso de memória: assim que as opções são passadas para o recurso de pool, o recurso mantém os parâmetros internamente, de modo que o próprio objeto PoolOptions pode ser destruído ou reutilizado com segurança. Pergunta (aberta)

Em relação à concorrência, a estrutura em si não oferece nenhum mecanismo inerente de sincronização. Acessos paralelos de leitura a um objeto PoolOptions não modificado são thread-safe, enquanto modificações simultâneas devem ser sincronizadas externamente. No entanto, como o objeto é configurado primariamente antes da passagem, em regra não ocorre mais nenhum acesso de escrita após a inicialização.

Caminho de utilização

O caso de uso primário engloba a definição dos limites de alocação e o repasse para um componente de gerenciamento de memória. Primeiro, o chamador cria uma instância de ara::core::PoolOptions e preenche os parâmetros desejados. Por meio de max_blocks_per_chunk, define-se o limite superior para blocos por chunk [SWS_CORE_00027], enquanto largest_required_pool_block define o limite superior para alocações que ainda devem ser cobertas pelo pool [SWS_CORE_00028].

Em seguida, a estrutura preenchida é passada ao construtor de um recurso de memória de pool correspondente. O recurso de memória lê os valores configurados e ajusta seus pools internos de acordo. Se chegarem solicitações de memória durante a operação em tempo de execução, o recurso decide, com base nos limiares previamente configurados, se a solicitação pode ser atendida a partir de um pool ou se deve ser encaminhada para um recurso upstream de nível superior. Interpretação: Deve-se assumir que solicitações que excedam largest_required_pool_block são tipicamente delegadas diretamente ao gerenciador de memória de nível superior. Pergunta (aberta)

Configuração e utilização de PoolOptionsAplicaçãoPoolOptionsSpeicherressourceUse Case: KonfigurationParameter max_blocks_per_chunke definir largest_required_pool_blockUse Case: Inicialização do recurso de memóriaConstrução com PoolOptionsOptionen auslesenRetornar valores de parâmetrosUse Case: Laufzeit-AllokationSpeicher anfordernSpeicherblock bereitstellen

Diagrama de sequência: fluxo típico da configuração de um recurso de memória de pool por meio de PoolOptions. Fontes: [SWS_CORE_00027], [SWS_CORE_00028].

Cenários de erro

Como ara::core::PoolOptions é definido como um agregado de dados simples (struct), a criação ou o preenchimento dos campos não lança exceções de C++ e não retorna códigos de erro. Condições potenciais de erro surgem apenas na interpretação dos valores pelo recurso de memória receptor.

Interpretação: Caso valores irrealistas sejam configurados — por exemplo, um valor extremamente grande para max_blocks_per_chunk [SWS_CORE_00027] ou para largest_required_pool_block [SWS_CORE_00028] —, isso pode fazer com que o recurso de memória posterior atinja os limites do sistema ao alocar chunks e dispare estados de out-of-memory. Portanto, a pré-condição para uma operação estável é uma harmonização cuidadosa de ambos os parâmetros com a memória física disponível e o perfil de carga esperado da aplicação. Se os valores permanecerem em 0, cabe ao recurso de destino aplicar tamanhos padrão robustos. Pergunta (aberta)

Este guia baseia-se na especificação AUTOSAR Adaptive Platform Release R25-11. Todas as declarações técnicas apoiam-se exclusivamente nos requisitos contidos no payload da especificação.

Diagrama de classes UML

Hohle Dreieckspfeile = Vererbung (zeigt zur Basisklasse); Klicken öffnet die jeweilige Klassenseite.

G nara__core__PoolOptions463 «struct» PoolOptions + largest_ + max_

Constantes

largest_ variável

≙ [mem.res.pool]

std::size_t largest_required_pool_block = 0;
max_ variável

≙ [mem.res.pool]

std::size_t max_blocks_per_chunk = 0;

Documentação das constantes / variáveis

variável largest_ [SWS_CORE_00028]

std::size_t largest_required_pool_block = 0;

As per corresponding usage in [mem.res.pool]

Header-Datei#include "ara/core/memory_resource.h"
Scopestruct ara::core::PoolOptions
Symbollargest_required_pool_block
Typstd::size_t

Request a governed re-review of this record. The record is not changed immediately.

Record
AUTOSAR/AP/record/SWS_CORE_00028
Status
valid/unmigrated
Version
AUTOSAR/AP/record/SWS_CORE_00028@rel:R25-11#2637e3c4
Content hash
2637e3c4
Source
https://www.autosar.org/fileadmin/standards/R25-11/AP/AUTOSAR_AP_SWS_Core.pdf#nameddest=SWS_CORE_00028
Status: valid/unmigrated Version: rel:R25-11#a3bf6d56 Versionshistorie & Revisions (1 transition, 3 revision)
Current State
valid/unmigrated
Reason
mechanically backfilled by migriere_status_backfill.py -- no per-field curation history exists yet for this record
Campaign
2026-08-13-status-backfill
Active Version
AUTOSAR/AP/record/SWS_CORE_00028@rel:R25-11#a3bf6d56
Point-in-Time History:
Recorded Revisions (3):
  • R25-11rel:R25-11#09a93b7f2026-09-30
  • R24-11rel:R24-11#0f29769e2026-10-14
  • R25-11rel:R25-11#a3bf6d562026-10-14 active
DateActorTransitionReason / RationaleCampaign
2026-08-13toolnone → valid/unmigratedmechanically backfilled by migriere_status_backfill.py -- no per-field curation history exists yet for this record2026-08-13-status-backfill

variável max_ [SWS_CORE_00027]

std::size_t max_blocks_per_chunk = 0;

As per corresponding usage in [mem.res.pool]

Header-Datei#include "ara/core/memory_resource.h"
Scopestruct ara::core::PoolOptions
Symbolmax_blocks_per_chunk
Typstd::size_t

Request a governed re-review of this record. The record is not changed immediately.

Record
AUTOSAR/AP/record/SWS_CORE_00027
Status
valid/unmigrated
Version
AUTOSAR/AP/record/SWS_CORE_00027@rel:R25-11#b9fcaa39
Content hash
b9fcaa39
Source
https://www.autosar.org/fileadmin/standards/R25-11/AP/AUTOSAR_AP_SWS_Core.pdf#nameddest=SWS_CORE_00027
Status: valid/unmigrated Version: rel:R25-11#fc3e04ef Versionshistorie & Revisions (1 transition, 3 revision)
Current State
valid/unmigrated
Reason
mechanically backfilled by migriere_status_backfill.py -- no per-field curation history exists yet for this record
Campaign
2026-08-13-status-backfill
Active Version
AUTOSAR/AP/record/SWS_CORE_00027@rel:R25-11#fc3e04ef
Point-in-Time History:
Recorded Revisions (3):
  • R25-11rel:R25-11#3e26306e2026-09-30
  • R24-11rel:R24-11#cd619fd92026-10-14
  • R25-11rel:R25-11#fc3e04ef2026-10-14 active
DateActorTransitionReason / RationaleCampaign
2026-08-13toolnone → valid/unmigratedmechanically backfilled by migriere_status_backfill.py -- no per-field curation history exists yet for this record2026-08-13-status-backfill