1TSEND(2) LAM NETWORK LIBRARY TSEND(2)
2
6 tsend, trecv - Send and receive LAM transport messages.
7
9 #include <net.h>
10 int tsend (struct nmsg *header);
12 int trecv (struct nmsg *header);
13
15 subroutine TSND (nnode, nevent, ntype, nlength, nflags, ndata, ndsize,
16 nmsg, ierror)
17 subroutine TRCV (nevent, ntype, nlength, nflags, ndata, ndsize, nmsg,
19 ierror)
20 integer nnode, nevent, ntype, nlength, nflags, ndata(*), ndsize,
22 nmsg(*), ierror
23
25 These transport message-passing routines add flow control to the net‐
26 work routines, nsend(2) and nrecv(2), and enable multiple processes to
27 send multi-packet messages to a receiver using the same event and type
28 while maintaining the atomicity of the messages. The sending process
29 sends a "ready-to-send" message to the receiver and blocks until the
30 receiving process signals that it is ready. The receiver returns to
31 the sender a new event, its process ID negated, to be used in the
32 transfer of the body of the message. The introduction of the second
33 event allows multi-packet messages, using the same event and destined
34 to the same node, to be received with no mixing up of packets. The
35 transport routines are also typically used while developing and debug‐
36 ging applications. Naturally, they have higher overhead than their
37 network counterparts.
38 The transport routines overcome the basic danger of LAM network mes‐
40 sage-passing - the lack of strong synchronization. A sending process
41 can transmit a message that may never be received due to programming
42 error or deadlock. This message will never be dropped or timed out.
43 Some LAM process will always be stuck with it, waiting for a synchro‐
44 nizing drecv(2) or nrecv(2) that will never happen. If that unfortu‐
45 nate process is a buffer, it can be located by the user and swept clean
46 (see sweep(1)). However, if the process is a link proprietor, the link
47 is henceforth plugged and useless.
48 The transport routines solve this problem by causing the sending
50 process to block until it receives a "ready-to-receive" protocol mes‐
51 sage from the receiving process. If due to a programming error there
52 is no receiving process at the other end, the "ready-to-send" message
53 is guaranteed not to plug a link proprietor. The second advantage in
54 this case is that the sender is stopped from flooding the system with
55 messages that no receiver will consume. After the pre-synchronizing
56 exchange, the network routines are invoked and the message is transmit‐
57 ted.
58 Use of the network message structure passed to tsend() and trecv() is
60 the same as described under nsend(2).
61
63 dsend(2), nsend(2)
64LAM 7.1.2 March, 2006 TSEND(2)