Newsgroups: comp.parallel.pvm
From: Erik Reinhard <reinhard@cs.bris.ac.uk>
Subject: Re: How to check buffer length?
Organization: University of Bristol, England
Date: Wed, 12 Aug 1998 14:32:45 GMT
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <35D1A78D.6BEA8490@cs.bris.ac.uk>

Clark E. Dorman wrote:

> I have been trying but I seem to be completely unable to post this to
the
> newsgroup.  I thought that you might like to read it though.
>
> Erik Reinhard <reinhard@cs.bris.ac.uk> writes:
> >
> > Here's a little PVM question that I haven't seen answered
> > in any manual or FAQ. I'd like to be able to find out how
> > many messages there are pending in an input buffer. Is there
> > a simple way of doing this? Ideally, I would like to specify
> > in true PVM style a tid and a message tag (possibly using
> > wildcards) and get returned the total number of messages
> > fitting that description in my input buffer.
>
> No, to the best of my knowledge there is no way to easily do this.
> pvm_probe will tell you the next message, but that is not going to do
> what you want.
>
> > The use for this to me is obvious. If I know my input buffer
> > contains too many messages, I may be able to redirect a number
> > of them to processors with a smaller workload. Is there any
> > other way to accomplish the same that I may have missed?
>
> The way to accomplish this is to receive the messages and store them,
> using pvm_setrbuf.  It is a pain, I know, but what you can do is make
> an array and add buffer id's as you read messages until they are all
> gone (maybe using pvm_probe to see if there is another message, but I
> generally use non-blocking receive), and then you can figure out what
> to do with the messages, based on the size of your array and what is
> in them, and then free the buffers.

Hi Clark,

Thanks for your e-mail. I've been thinking about this problem
over the last few days and I think there are two solutions which
avoid receiving and storing the messages. One is PVM 3.3 compatible
and the other isn't. Your solution is another one, which I hadn't
thought
of. Thanks for the suggestion. Here's what I was thinking:

First, in PVM 3.4 it should be possible to use the message handler
scheme to

(using pvm_addmhf) to install a handler which increments the number of
messages so far. When the message is later received the usual way, the
counter is decremented again. This must be the most efficient way to
keep track of the size of the input buffer. Unfortunately, I'll be using

PowerPVM, which is a PVM 3.3 compatible implementation. So I
thought I'd implement the following (which seems to work, albeit
not the most efficient way of doing this, probably):

int buffer_length[CLASSCOUNT];

static int match_count (mid, tid, tag)
  int mid;
  int tid;
  int tag;
{
  if (pvm_bufinfo(mid, (int*)0, &tag, &tid) >= 0)
    buffer_length[tag]++;
  return 0;
}


void pvm_count_input ()
{
  int (*omatch)();

  memset ((void *)buffer_length, 0, CLASSCOUNT * sizeof (int));
  omatch = pvm_recvf (match_count);
  (void)pvm_probe (-1, -1);
  pvm_recvf (omatch);
}

Calling pvm_count_input will result in an array (buffer_length) which
got
for each tag the number of messages in the input buffer.

Cheers,
Erik