Modes of Operation
Calling Semantics
Asynchronous (Polled)
Hardware “request/response” interface is inherently asynchronous (non-blocking).
Calling function returns once request submitted.
Callback invoked when response available (polled).

Asynchronous (Interrupts)
Hardware “request/response” interface is inherently asynchronous (non-blocking).
Calling function returns once request submitted.
Callback invoked when response available (interrupt-driven).

Synchronous
Software interface is traditionally synchronous (blocking).
Calling function blocks until response available.
Can be implemented “on top of” asynchronous hardware semantics.

Pros And Cons
Asynchronous |
Synchronous |
|
---|---|---|
CPU Utilization
|
Software thread can do other things
while hardware processes job,
without need for expensive context
switch.
|
Software thread blocked or idle awaiting response.
Can use multi-threading, but context switching can be expensive.
|
Acceleration
Utilization
|
A single software thread can have
multiple requests outstanding,
keeping multiple accelerator engines.
|
Hardware has at most one request outstanding per CPU/software
thread, remaining threads are idle.
|
Ease of Use
|
Can be difficult if application is
designed to use synchronous APIs.
|
Easier to integrate if application is designed to use
synchronous APIs.
|
Note
Asynchronous API tends to be optimal for performance, but harder to integrate.