In order to reduce the cost of context switching and signal delivery delays in the kernel, the AM dispatch handler can be optimized. Once the user's handler has executed and returned to the dispatcher, the network interface is again checked for data. If another message is received, the user's handler will again be called and the entire process repeated. If no data is available, the user's process is allowed to continue processing where it left off.
A nice optimization can be made regarding the search of the request table for stale timestamps. Instead of scanning the entire table during each operation, only one entry need be examined. The major motivation is that the pattern of reference to this table is cyclic during normal operation. As long as the user is communicating or periodically checking this table during computation, the data is guaranteed to be delivered.
One can easily imagine a situation where a cluster of nodes is performing some computation and then pushing data to each of their neighbors. This type of operation requires only that data be sent during the request phase. Even on a small network, this could easily result in considerable duplicate processing in the form of a reply-request loop, with each requiring the construction of a separate message. A simple optimization is to ``piggyback'' replies whenever possible. Thus, with the addition of one field to the request message-the reply instance number-we have reduced the message-formatting work by 50 percent.