SNIP_CLASSIC_STD_SECTION_4_3_1_5_2_Explicit

4.3.1.5.2 Explicit The behavior of explicit reception depends on the category of the runnable and on the configuration of the according ports. An explicit API call can be either non-blocking or blocking. If the call is non-blocking (i.e. there is a VariableAccess in the dataReceivePointByValue or dataReceivePointByArgument role referencing the VariableDataPrototype for which the API is being generated, but no WaitPoint referencing a DataReceivedEvent which references the VariableDataPrototype for which the API is being generated), the API call immediately returns the next value to be read and, if the communication is queued (event reception), it removes the data from the receiver-side queue, see Section 4.3.1.10 [SWS_Rte_06012] Upstream requirements: SRS_Rte_00109 ⌈A non-blocking RTE API “read” call shall indicate if no data is available.⌋ In contrast, a blocking call (i.e. the VariableDataPrototype, referenced by a VariableAccess in the role dataReceivePointByArgument, and for which the API is being generated, is referenced by a DataReceivedEvent which is itself referenced by a WaitPoint) will suspend execution of the caller until new data arrives (or a timeout occurs) at the according port. When new data is received, the RTE resumes the execution of the waiting runnable. ([SRS_Rte_00092]) To prevent infinite waiting, a blocking RTE API call can have a timeout applied. The RTE monitors the timeout and if it expires without data being received returns a particular error status. [SWS_Rte_06013] Upstream requirements: SRS_Rte_00069 ⌈A blocking RTE API “read” call shall indicate the expiry of a timeout.⌋ The “timeout expired” indication also indicates that no data was received before the timeout expired. Blocking reception of data (“wake up of wait point” receive mode as described in Section 4.3.1.2) is only applicable for category 2 runnables whereas non-blocking reception (“explicit data read access” receive mode) can be employed by runnables of category 2 or 1B. Neither blocking nor non-blocking explicit reception is applicable for category 1A runnable because they must not invoke functions with unknown execution time (see table 4.8). [SWS_Rte_06016] Upstream requirements: SRS_Rte_00098 ⌈The RTE API call for explicit sending (VariableAccessin the dataSendPoint role, [SRS_Rte_00098]) shall be non-blocking.⌋ Using this API call, the runnable can explicitly send new values of the VariableDataPrototype. Explicit writing is valid for runnables of category 1b and 2 only. Explicit writing is not allowed for a category 1A runnable since these require API calls with constant execution time (i.e. macros). Although the API call for explicit sending is non-blocking, it is possible for a category 2 runnable to block waiting for a notification whether the (explicit) send operation was successful. This is specified by the AcknowledgementRequest attribute and occurs by a separate API call Rte_Feedback. If the feedback method is ’wake_up_of_wait_point’, the runnable will block and be resumed by the RTE either when a positive or negative acknowledgment arrives or when the timeout associated with the WaitPoint expires.