3.3 Synchronous and asynchronous behavior

When calling a function, you can generally choose either to generate a synchronous request, which will later be answered by the callee with a response, or you can generate an asynchronous notification for which no response is generated.

Requests enable the caller to know when the callee has finished with the function, while notifications do not. This is relevant in the following use-cases:

Synchronous or asynchronous event callbacks

When enabling an event callback, the event consumer can choose:

  • Whether the event-generating instance should be blocked while the consumer processes the event. This is a synchronous callback, using a request and a response for each event, see syncEc=True argument to eventStream_create().
  • Whether the event-generating instance should continue running, without waiting for the event to be processed. This is an asynchronous callback, using a notification.

Overlapping function calls

In general it is unnecessary to wait for a response before issuing the next request, except for instances that generate an event callback when syncEc=True. This means that function calls can overlap.

For example, if a debugger wants to read all registers, some memory, and a table of information, it issues the following requests without waiting for them to complete:

  • resource_read(), request id=707.
  • memory_read(), request id=708.
  • table_read(), request id=709.

It then waits for the responses to requests 707, 708, and 709 in any order. This reduces the round-trip latency, for example through a TCP connection, from three round trips to one round trip, but makes the code more complex.

Non-ConfidentialPDF file icon PDF version101196_0100_03_en
Copyright © 2018, 2019 Arm Limited or its affiliates. All rights reserved.