TSEND(2) LAM NETWORK LIBRARY TSEND(2)NAME
tsend, trecv - Send and receive LAM transport messages.
C SYNOPSIS
#include <net.h>
int tsend (struct nmsg *header);
int trecv (struct nmsg *header);
FORTRAN SYNOPSIS
subroutine TSND (nnode, nevent, ntype, nlength, nflags, ndata, ndsize,
nmsg, ierror)
subroutine TRCV (nevent, ntype, nlength, nflags, ndata, ndsize, nmsg,
ierror)
integer nnode, nevent, ntype, nlength, nflags, ndata(*), ndsize,
nmsg(*), ierror
DESCRIPTION
These transport message-passing routines add flow control to the net‐
work routines, nsend(2) and nrecv(2), and enable multiple processes to
send multi-packet messages to a receiver using the same event and type
while maintaining the atomicity of the messages. The sending process
sends a "ready-to-send" message to the receiver and blocks until the
receiving process signals that it is ready. The receiver returns to
the sender a new event, its process ID negated, to be used in the
transfer of the body of the message. The introduction of the second
event allows multi-packet messages, using the same event and destined
to the same node, to be received with no mixing up of packets. The
transport routines are also typically used while developing and debug‐
ging applications. Naturally, they have higher overhead than their
network counterparts.
The transport routines overcome the basic danger of LAM network mes‐
sage-passing - the lack of strong synchronization. A sending process
can transmit a message that may never be received due to programming
error or deadlock. This message will never be dropped or timed out.
Some LAM process will always be stuck with it, waiting for a synchro‐
nizing drecv(2) or nrecv(2) that will never happen. If that unfortu‐
nate process is a buffer, it can be located by the user and swept clean
(see sweep(1)). However, if the process is a link proprietor, the link
is henceforth plugged and useless.
The transport routines solve this problem by causing the sending
process to block until it receives a "ready-to-receive" protocol mes‐
sage from the receiving process. If due to a programming error there
is no receiving process at the other end, the "ready-to-send" message
is guaranteed not to plug a link proprietor. The second advantage in
this case is that the sender is stopped from flooding the system with
messages that no receiver will consume. After the pre-synchronizing
exchange, the network routines are invoked and the message is transmit‐
ted.
Use of the network message structure passed to tsend() and trecv() is
the same as described under nsend(2).
SEE ALSOdsend(2), nsend(2)LAM 7.1.2 March, 2006 TSEND(2)
