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 $
> > 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.
> Jeff Squyres
> Cisco Systems
> devel mailing list