AM is a low-latency communication mechanism for multiprocessors that emphasizes the overlap of communication and computation [12]. Messages are in the form of requests and matching replies and contain the address of a handler that is invoked on receipt of the message along with up to four words of arguments. The handler pulls the arguments out of the network, integrates them into the ongoing computation and potentially sends a reply back. Large messages are sent using bulk transfer operations called stores and gets which transfer data between blocks of memory specified by the node initiating the transfer.
Message delivery is generally done by explicit network polling in which case each call to am_request checks the network and explicit checks can be added using am_poll. Interrupt-driven reception is also available but not used in this analysis of SP AM. AM guarantees reliable delivery of messages but does not recover from crash failures, network partitions, and other similar kinds of failures. The interface is summarized in Table 1.
Table: Summary of AM interface.
Am_request_M functions invoke the handler on the remote
node with 
as parameters.
The handler may reply using similar am_reply_M functions.
Am_store copies nbytes of local data to the specified remote
address and invokes a handler on the remote node after the transfer is
complete.
Am_store blocks until the source memory region can be reused,
while am_store_async returns immediately and a separate completion
function is called on the sending side at the end of the data transfer.
Am_get initiates
a data transfer from a remote memory block to a local one and invokes
a local handler at the end of the transfer.