Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

From: Sven Stork (stork_at_[hidden])
Date: 2007-08-17 08:22:11


On Friday 17 August 2007 13:58, Jeff Squyres wrote:
> On Aug 16, 2007, at 1:13 PM, Tim Prins wrote:
>
> >> So you're both right. :-) But Tim's falling back on an older (and
> >> unfortunately bad) precedent. It would be nice to not extend that
> >> bad precedent, IMHO...
> >
> > I really don't care where the constants are defined, but they do
> > need to
> > be unique. I think it is easiest if all the constants are stored in
> > one
> > file, but if someone else wants to chop them up, that's fine with
> > me. We
> > would just have to be more careful when adding new constants to check
> > both files.
>
> Ya, IIRC, this is a definite problem that we had: it's at the core of
> the "component" abstraction (a component should be wholly self-
> contained and not have any component-specific definitions outside of
> itself), but these tags are a central resource that need to be
> allocated in a distributed fashion.
>
> That's why I think it was decided to simply leave them as they were,
> and/or use the (DYNAMIC-x) form. I don't have any better suggestion;
> I'm just providing rationale for the reason it was the way it was...
>
> >> True. We will need a robust tag reservation system, though, to
> >> guarantee that every process gets the same tag values (e.g., if udapl
> >> is available on some nodes but not others, will that cause openib to
> >> have different values on different nodes? And so on).
> > Not really. All that is needed is a list of constants (similar to the
> > one in rml_types.h).
>
> I was assuming a dynamic/run-time tag assignment (which is obviously
> problematic for the reason I cited, and others). But static is also
> problematic for the breaking-abstraction reasons. Stalemate.

What's about this. Every component choose its own tag independent from the
others. Before a component can use the tag it must register with its full
name and the tag at a small (process intern) database. If 2 components try to
register the same tag we emit a warning, terminate the processes, ... .

If 2 components (CompA and CompB) want to register the same tag and we assume
that process A loads _only_ CompA while processes B loads _only_ CompB than
both components will be loaded without any error.
I assume that it's rather unusual that CompA send a message to process B as
there is no counter component. But there is still some probability.

For more safety (and of course less performance) we could :
- add a parameter that cause this tag database to sync. across all processes.
- add a parameter that turns a check for every send/receive, if the specified
tag has been used or not

Just my 0.02 $
   Sven

> > If a rsl component doesn't like the particular
> > constant tag values, they can do whatever they want in their
> > implementation, as long as a messages sent on a tag is received on the
> > same tag.
>
> Sure.
>
> --
> Jeff Squyres
> Cisco Systems
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>