At any given time, the maximum number of active send buffers a Parallel…

Concept

Message-passing libraries differ in how an application hands data to the network. One widely used design, and the one PVM adopts, is an implicit current-buffer interface: the application packs data into a library-managed send buffer and unpacks arriving data from a library-managed receive buffer, and the library keeps at most one buffer in each direction designated as the active buffer, so that the pack and unpack calls need carry no buffer argument at all. A task may allocate any number of further buffers, but they stay inactive until they are explicitly promoted, and the active designation can also be cleared so that no buffer is active in that direction. Libraries built on a different design, such as MPI, instead take the application's own address and length on every call and have no active-buffer notion at all.

Applying it here

PVM follows exactly that design: at any given time the maximum number of active send buffers a PVM task can have is one, and the maximum number of active receive buffers it can have is one, which makes the pairing one-one. The message life cycle shows why one of each is the ceiling:

1. pvm_initsend() clears and designates the active send buffer, choosing the encoding for the message about to be built.

2. Every pvm_pkint() / pvm_pkstr() call packs into that one active send buffer — notice the call signature carries no buffer id, because the target is implicit.

3. pvm_send() or pvm_mcast() transmits whatever the active send buffer currently holds.

4. pvm_recv() / pvm_nrecv() accepts an arriving message and makes it the active receive buffer.

5. Every pvm_upkint() / pvm_upkstr() call then unpacks from that one active receive buffer, again with no buffer id in the signature.

Cross-check and contrast

• PVM does let a task own several message buffers: pvm_mkbuf() creates extra ones and pvm_setsbuf() / pvm_setrbuf() swap which buffer is active, returning the previously active one. Many buffers may exist at once, but the ceiling on how many are active per direction is still one each, and the stem asks about that active count.

• The design is self-consistent: if two send buffers were active simultaneously, pvm_pkint() would be ambiguous about where to write, and the API would have to take a buffer handle. It does not, which is exactly the signature of a single active buffer per direction.

• A count of two in either direction describes the multi-buffer pvm_mkbuf() allocation capability rather than the active-buffer designation, so it answers a different question than the one asked.

• The bound is "at most one", not "always exactly one": pvm_setsbuf(0) and pvm_setrbuf(0) save the current buffer and leave the task with no active buffer in that direction until one is set again. The ceiling per direction is one either way, so the pairing the stem asks for is unaffected.

Reference: PVM 3 User’s Guide and Reference Manual, ORNL/TM-12187 (Oak Ridge National Laboratory / netlib).