Newsgroups: comp.parallel.pvm
From: Graham Nash <gnash@ncube.com>
Subject: Re: Does pvm_bcast work?
Organization: Integratek
Date: Thu, 6 Jun 1996 20:32:25 GMT
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <31B74059.4A31@ncube.com>

Graham Nash wrote:
> 
> M. Mueller wrote:
> >
> > I've got a problem with the pvm_bcast()-call. The application's
> > waiting all the time. When I use pvm_mcast() instead - it works.
> >
> > Is there a problem with the group-to-tid-conversion?
> > I'd like to know, whether there are applications that use
> > pvm_bcast and work.
> >
> I have not had it happen, but in general the group functions act up
> if you have tasks that quit PVM out of sync with the others. If you
> do not call pvm_freezegroup which takes a snapshot of the membership
> and stores this away, the group functions poll the group server and if
> they are not synchronised, this latter can report back different
> memberships to different tasks. This is a major problem with the
> group reduction functions that appear to work but often miss some of the
> contributions (annoying if these are part of the results).
> 
> I confess not to see immediately why bcast fails but it does not
> surprise me. Try calling pvm_freezegroup after everyone is up and
> running (this needs care) so that everyone has a consistent view of
> the group, or do a pvm_barrier before exiting.
> 

It's a little silly replying to one's own reply, but it strikes me the
pb could be in the startup. Before doing anything, it is advisable to
pvm_barrier on the number of expected tasks. This ensures that everyone
has a consistent view of the group. Otherwise, an early task performs
a bcast to a group that has not yet all its members. Those present
will receive their messages, those not yet started or enrolled in the
group will probably hang (since they never receive the message).

Thus the golden rule with groups is synchronise when you start and when 
you terminate.

Graham

