estrutura ara::diag::SovdContentConcurrencyType

A struct ara::diag::SovdContentConcurrencyType especifica o comportamento de simultaneidade para conteúdos SOVD relativos a portas no AUTOSAR Adaptive [SWS_DM_02182]. Controla, através de três atributos, se o Diagnostic Management pode executar operações de leitura e escrita na porta da aplicação em paralelo ou se tem de as serializar. Por padrão, todos os campos são inicializados defensivamente com kNotConcurrent, pelo que os programadores têm de autorizar explicitamente a concorrência como em readWrite [SWS_DM_02185]. A configuração deve estar concluída antes do início da comunicação de diagnóstico, a fim de assegurar um processamento thread-safe.

mais ›

Contexto

A estrutura de dados ara::diag::SovdContentConcurrencyType está declarada no cabeçalho ara/diag/concurrency.h e serve para especificar o comportamento de concorrência para portas no contexto de Service-Oriented Vehicle Diagnostics (SOVD) [SWS_DM_02182]. Em arquiteturas baseadas na AUTOSAR Adaptive Platform, o Diagnostic Management (DM) atua como entidade central para o processamento de pedidos de diagnóstico recebidos SWS Diagnostics p. 79. Quando clientes de diagnóstico externos iniciam acessos de leitura ou escrita a conteúdos de diagnóstico através de SOVD, o Diagnostic Management tem de conseguir determinar se a Adaptive Application fornecedora ou a respetiva porta tem capacidade para processar múltiplos pedidos de forma concorrente e thread-safe.

Para o efeito, SovdContentConcurrencyType define três atributos de configuração para acessos exclusivos de leitura, acessos exclusivos de escrita e acessos combinados de leitura e escrita SWS Diagnostics §8.8.3 «Struct: SovdContentConcurrencyType». A estrutura atua, assim, como interface de configuração entre a implementação da porta do lado da aplicação e o controlo de fluxo do Diagnostic Management.

Diagrama de contexto: interação entre o Diagnostic Management, SovdContentConcurrencyType e a porta SOVD da Adaptive Application. Fontes: [SWS_DM_02182], [SWS_DM_02185], SWS Diagnostics §8.8.3 «Struct: SovdContentConcurrencyType»

Ciclo de vida

Enquanto struct pura de transferência de dados e de configuração, SovdContentConcurrencyType possui um ciclo de vida simples sem gestão dinâmica de recursos ou controlos de estado internos complexos [SWS_DM_02182].

A instanciação ocorre tipicamente durante a fase de configuração e inicialização da Adaptive Application, presumivelmente na pilha ou como parte de uma classe de gestão de portas de nível superior antes do início da comunicação de diagnóstico. Pergunta Q-f78487eff58a4775 (aberta) Todas as variáveis-membro são inicializadas defensivamente por defeito aquando da criação do objeto:

• read é predefinido por padrão com ConcurrencyType::kNotConcurrent [SWS_DM_02183].
• write é predefinido por padrão com ConcurrencyType::kNotConcurrent [SWS_DM_02184].
• readWrite é predefinido por padrão com ConcurrencyType::kNotConcurrent [SWS_DM_02185].

No que diz respeito à concorrência e ao threading, aplica-se o seguinte: a struct em si é um objeto de configuração passivo sem mecanismos de sincronização próprios. As modificações nos campos devem, portanto, estar concluídas antes de a estrutura ser passada para o Diagnostic Management ou lida por várias threads. Após o registo na porta, a configuração permanece inalterada durante todo o tempo de vida da respetiva porta de diagnóstico (Interpretação: uma modificação dinâmica em tempo de execução da comunicação de diagnóstico não está prevista pela especificação). Pergunta Q-71f96ed7cd3a6f61 (aberta) A limpeza da instância da estrutura ocorre após o fim do seu âmbito de validade, de acordo com a semântica regular de C++, sem necessidade de limpeza adicional.

Caminho de utilização

O percurso de utilização típico compreende a definição das capacidades da porta pela aplicação, a disponibilização em tempo de execução e a avaliação pelo Diagnostic Management:

1. Configuração das capacidades: a Adaptive Application instancia um objeto do tipo SovdContentConcurrencyType. Se a implementação dos métodos da porta estiver concebida para ser thread-safe, os respetivos atributos são definidos deliberadamente com ConcurrencyType::kConcurrent. A definição de readWrite como kConcurrent sinaliza explicitamente ao Diagnostic Management que as APIs de leitura e escrita podem ser chamadas em simultâneo [SWS_DM_02185].
2. Preservação do comportamento predefinido: desde que uma implementação de porta não seja reentrante ou sincronizada internamente, o programador mantém os valores em kNotConcurrent [SWS_DM_02183], [SWS_DM_02184]. Interpretação: neste caso, o Diagnostic Management assegura que os pedidos pendentes para esta porta sejam executados sequencialmente, de modo a evitar conflitos de dados. Pergunta (aberta)
3. Controlo de fluxo pelo DM: durante a operação, o Diagnostic Management recebe pedidos SOVD externos. Com base na configuração registada, o DM determina se as chamadas de método paralelas para rotinas de leitura e escrita podem ser encaminhadas para a porta ou se uma serialização é estritamente necessária SWS Diagnostics §8.8.3.1.2 «readWrite».