SNIP_CLASSIC_STD_SECTION_4_3_1_2_Receive_Modes

4.3.1.2 Receive Modes The RTE supports multiple receive modes for passing data to receivers. The four possible receive modes are: • “Implicit data read access” – when the receiver’s runnable executes it shall have access to a “copy” of the data that remains unchanged during the execution of the runnable. [SWS_Rte_06000] Upstream requirements: SRS_Rte_00128, SRS_Rte_00019 ⌈For data elements specified with implicit data read access, the RTE shall make the receive data available to the runnable through the semantics of a copy.⌋ [SWS_Rte_06001] Upstream requirements: SRS_Rte_00128 ⌈For data elements specified with implicit data read access the receive data shall not change during execution of the runnable.⌋ When “implicit data read access” is used the RTE is required to make the data available as a “copy”. It is not necessarily required to use a unique copy for each runnable. Thus the RTE may use a unique copy of the data for each runnable entity or may, if several runnables (even from different components) need the same data, share the same copy between runnables. Runnable entities can only share a copy of the same data when the scheduling structure can make sure the contents of the data is protected from modification by any other party. [SWS_Rte_06004] Upstream requirements: SRS_Rte_00128 ⌈The RTE shall read the data elements specified with implicit data read access before the associated runnable entity is invoked.⌋ Composite data types shall be handled in the same way as primitive data types, i.e. RTE shall make a “copy” available for the RunnableEntity. [SWS_Rte_06003] Upstream requirements: SRS_Rte_00134 ⌈The “implicit data read access” receive mode shall be valid for all categories of runnable entity (i.e. 1A, 1B and 2).⌋ • “Explicit data read access” – the RTE generator creates a non-blocking API call to enable a receiver to poll (and read) data. This receive mode is an “explicit” mode since an explicit API call is invoked by the receiver. The explicit “data read access” receive mode is only valid for category 1B or 2 runnable entities [SRS_Rte_00134]. • “wake up of wait point” – the RTE generator creates a blocking API call that the receiver invokes to read data. [SWS_Rte_06002] Upstream requirements: SRS_Rte_00109, SRS_Rte_00069 ⌈The “wake up of wait point” receive mode shall support a time-out to prevent infinite blocking if no data is available.⌋ The “wake up of wait point” receive mode is inherently only valid for a category 2 runnable entity. A category 2 runnable entity is required since the implementation may need to suspend execution of the caller if no data is available. • “activation of runnable entity” – the receiving runnable entity is invoked automatically by the RTE whenever new data is available. To access the new data, the runnable entity either has to use “implicit data read access” or “explicit data read access”, i.e. invoke an Rte_IRead, Rte_Read, Rte_DRead or Rte_Receive call, depending on the input configuration. This receive mode differs from “implicit data read access” since the receiver is invoked by the RTE in response to a DataReceivedEvent. [SWS_Rte_06007] Upstream requirements: SRS_Rte_00134 ⌈The “activation of runnable entity” receive mode shall be valid for category 1A, 1B and 2 runnable entities.⌋ The validity of receive modes in conjunction with different categories of runnable entity is summarized in Table 4.8. Receive Mode Cat 1A Cat 1B Cat 2 Implicit Data Read Access Yes Yes Yes Explicit Data Read Access No Yes Yes Wake up of wait point No No Yes Activation of runnable entity Yes Yes Yes Table 4.8: Receive mode validity The category of a runnable entity is not an inherent property but is instead determined by the features of the runnable. Thus the presence of explicit API calls makes the runnable at least category 1B and the presence of a WaitPoint forces the runnable to be category 2.