Subject: Re: descriptors vs ID's

From: [email-masked]
Date: Wed, 10 Mar 93 10:19:42 PST

(This is a resend.  Apparently several addresses got fouled up yesterday.)

Rik said:

> But I argue that the global ID's should NOT be the things that get
> passed to the collective comm routines, and possibly not even to the
> pt-pt routines.
> 
> Passing a global ID implies some kind of table searching, unless we
> put tight bounds on the value ranges so that we can do a simple
> indirection.

Of course, I suppose I could equally well argue that the cost of such
a lookup would be small compared to the overall cost of the
collective comm routine.  

Maybe this is a don't-care.

--Rik

(Good grief, Lyndon -- replying to one's own mail seems to be catching!)

---

From: [email-masked]
Date: Wed, 10 Mar 93 10:47:12 PST

(This is a resend with modifications [flagged with **].  
 The original, yesterday, had fouled up addresses.)

Jim raises the issue:

>    Are the tid's of local or global scope. i.e. Can I pass a tid to
>    someone else, and it still work as an address for the person I
>    passed it to ?
> For global scope : It's simpler for the user
> Against          : The implementor might want the "opaque identifier"
>                    to be a pointer to a big data structure containing
>                    route tables or something.

The same problem arises with groups and I'm not sure where else.

I agree that we need global scope ID's for tids and probably for groups.

For tid's, that's OK because there are only as many tid's as there
are processes, and I'm willing to believe that's a small bound.

But in theory there can be lots more groups than processes, and even
in practice I'm not sure that we can keep the global ID's both
unique and small without excessive overhead.  (E.g., recall my
trick of generating unique context values without communication
by cramming the creator's process number into the bottom bits.)

I propose that most routines be passed a local descriptor reference,
rather than the global ID value.

** The above may be don't-care.  For collective comms, the cost 
** of finding a (local) group descriptor, given the group ID, 
** is arguably small compared to the cost of the comm itself.
** For tid's, perhaps the tid values can be kept small enough to
** permit simple indirection.

Then we need either

  1. routines to retrieve the global ID from a local descriptor (easy)
     and to construct a local descriptor from the global ID (harder)
or
  2. a mechanism to translate local descriptors to and from some
     machine-independent form.

I prefer the second option because of my bias against servers.

** In another message, I raised the problem of maintaining
** coherence of group descriptors if the group ID's can be reused.
** The comments above also relate to methods of explicitly
** restoring coherency.  Scheme 1 would be used if a process was
** told only "group XX has been redefined, please invalidate your
** descriptor"; scheme 2 would be used if a process was told
** "group XX has been redefined and here's the new definition".

--Rik Littlefield