struct ara::core::PoolOptions

De structuur ara::core::PoolOptions dient voor de configuratie van poolgebaseerde geheugenbronnen conform std::pmr::pool_options. Zij maakt de begrenzing van het maximale aantal blokken per chunk via max_blocks_per_chunk [SWS_CORE_00027] mogelijk, evenals de vastlegging van de maximale pool-blokgrootte via largest_required_pool_block [SWS_CORE_00028]. Als eenvoudig data-aggregaat wordt de structuur vóór de initialisatie van de geheugenbron ingevuld en doorgegeven aan de constructor ervan. Interpretatie: Aangezien er geen eigen validatie plaatsvindt, moeten ontwikkelaars ervoor zorgen dat de geconfigureerde drempelwaarden het fysieke werkgeheugen niet overbelasten. Vraag (open)

meer ›

Context

De datastructuur ara::core::PoolOptions stelt configuratieparameters beschikbaar voor geheugenpoolgebaseerde bronnen in de module core van het AUTOSAR Adaptive Platform. Zij dient voor de gerichte besturing van het allocatiegedrag en sluit aan bij de C++-standaardfunctionaliteit van std::pmr::pool_options. De structuur wordt ingevoegd via de header <ara/core/memory_resource.h> en heeft een nauwe interactie met pool-geheugenbronnen, die aaneengesloten chunks en blokken aanhouden voor terugkerende geheugenaanvragen.

In veiligheidskritieke en realtime-nabije systemen is het begrenzen en voorspelbaar houden van dynamische geheugenoperaties essentieel. ara::core::PoolOptions vervult in deze context de rol van ontkoppelaar tussen applicatiespecifieke capaciteitseisen en het interne beheer van de geheugenpools. Via de structuur kunnen ontwikkelaars bepalen hoeveel blokken maximaal binnen één chunk mogen worden samengevoegd [SWS_CORE_00027] en welke maximale blokgrootte nog via de gespecialiseerde pools moet worden bediend [SWS_CORE_00028]. Toepassingssoftware die geheugenbronnen instantieert, gebruikt deze opties om overmatige fragmentatie te voorkomen en allocatiegrenzen deterministisch te sturen.

Levenscyclus

Als eenvoudig configuratietype (struct) heeft ara::core::PoolOptions een lichtgewicht levenscyclus zonder complexe interne toestandsovergangen. De aanmaak vindt typisch plaats als lokaal stack-object of als statische configuratieconstante vóór de instantiëring van de bijbehorende geheugenbron. Bij instantiëring worden de twee attributen max_blocks_per_chunk [SWS_CORE_00027] en largest_required_pool_block [SWS_CORE_00028] standaard geïnitialiseerd met de waarde 0.

Interpretatie: Een waarde van 0 zou voor de ontvangende geheugenresource moeten aangeven dat platformspecifieke standaardlimieten van toepassing moeten zijn. Vraag (open) Aangezien het om een zuiver waarde-object gaat, bezit ara::core::PoolOptions geen resources in de zin van RAII en voert het bij vernietiging geen opschoonacties uit. De levenscyclus van de structuur is gewoonlijk gekoppeld aan de creatiefase van de geheugenresource: zodra de opties aan de pool-resource zijn doorgegeven, behoudt de resource de parameters intern, zodat het PoolOptions-object zelf veilig vernietigd of hergebruikt kan worden.

Wat betreft concurrency biedt de structuur zelf geen inherent synchronisatiemechanisme. Parallelle leestoegangen tot een ongewijzigd PoolOptions-object zijn thread-safe, terwijl gelijktijdige wijzigingen extern moeten worden gesynchroniseerd. Omdat het object echter primair vóór de overdracht wordt geconfigureerd, vindt na de initialisatie over het algemeen geen schrijftoegang meer plaats.

Gebruikspad

De primaire usecase omvat het definiëren van de allocatiegrenzen en het doorgeven ervan aan een geheugenbeherende component. Eerst maakt de aanroeper een instantie van ara::core::PoolOptions aan en vult deze met de gewenste parameters. Via max_blocks_per_chunk wordt de bovengrens voor blokken per chunk vastgelegd [SWS_CORE_00027], terwijl largest_required_pool_block de bovengrens definieert voor allocaties die nog door de pool moeten worden gedekt [SWS_CORE_00028].

Vervolgens wordt de ingevulde structuur doorgegeven aan de constructor van een corresponderende pool-geheugenresource. De geheugenresource leest de geconfigureerde waarden uit en richt zijn interne pools dienovereenkomstig in. Komen er tijdens het bedrijf geheugenverzoeken binnen, dan beslist de resource aan de hand van de eerder geconfigureerde drempelwaarden of het verzoek vanuit een pool kan worden afgehandeld of moet worden doorgestuurd naar een bovenliggende upstream-resource. Interpretatie: Er mag van worden uitgegaan dat verzoeken die largest_required_pool_block overschrijden, typisch direct aan de bovenliggende geheugenbeheerder worden gedelegeerd. Vraag (open)

Sequentiediagram: Typisch verloop van de configuratie van een pool-geheugenresource via PoolOptions. Bronnen: [SWS_CORE_00027], [SWS_CORE_00028].

Foutscenario's

Omdat ara::core::PoolOptions als een eenvoudig data-aggregaat (struct) is gedefinieerd, werpt het aanmaken of invullen van de velden geen C++-excepties op en levert het geen foutcodes op. Potentiële foutsituaties ontstaan pas bij de interpretatie van de waarden door de ontvangende geheugenresource.

Interpretatie: Als er onrealistische waarden worden geconfigureerd — bijvoorbeeld een extreem grote waarde voor max_blocks_per_chunk [SWS_CORE_00027] of voor largest_required_pool_block [SWS_CORE_00028] —, kan dit ertoe leiden dat de nageschakelde geheugenresource bij de allocatie van chunks tegen systeemgrenzen aanloopt en out-of-memory-toestanden veroorzaakt. Vraag (open) Een randvoorwaarde voor een stabiele werking is daarom een zorgvuldige afstemming van beide parameters op het fysiek beschikbare werkgeheugen en het verwachte belastingsprofiel van de applicatie. Blijven de waarden op 0 staan, dan is het aan de doelresource om robuuste default-groottes toe te passen.