2.10.3 Ordering rules for requests, notifications, and responses

Notifications and responses are asynchronous and can be called from any host thread. A response might be received before or after irisHandleMessage(request) returns.

The following ordering rules apply to requests, notifications, and responses:

  • All requests, notifications, and responses from instance A to instance B arrive at instance B in the same order they were sent by instance A, if the order of these events was defined in A at all. If events E1 and E2 are generated in A with no implicit or explicit order, for example from two simulation threads without explicit synchronization, then the order of E1 and E2 is also undefined in B.
  • All requests from instance A to instance B are completed in order at instance B. This means for function calls F1 and then F2 from A to B that F2 only starts to have an effect on B after F1 has completed, in other words, after B has sent the response for F1. F1 and F2 do not run concurrently.
  • When instance A receives a response for function call F1 from instance B, function F1 has completed in B.
  • When instance B receives the global event ec_FOO(IRIS_SIMULATION_TIME_EVENT, RUNNING=False), which causes the simulation time to stop, it can be sure that it has received all requests and notifications that were generated up to and including this event.

These ordering rules have the following effects:

  • Sending a sequence of requests or notifications from one instance to another without waiting for a response executes the requests or notifications in the order in which they were sent.
  • Sending requests from one instance to another and waiting for the response to each request before sending the next request executes all requests in the order they were called.
  • If instances A1 and A2 send notifications, for example events, to instance B, there are no guarantees about the order in which B receives the events. However, B receives all events from A1 in the order that A1 generated them, and all events from A2 in the order that A2 generated them. Also, if a transaction travels through A1 and A2 and back again using a causal path, then all events generated on the way arrive at instance B in the same causal order. B implicitly serializes these causally-related events in the correct order, by queuing incoming IrisInterface::irisHandleMessage()s.
Non-ConfidentialPDF file icon PDF version101196_0100_00_en
Copyright © 2018 Arm Limited or its affiliates. All rights reserved.