Subject: Re: Restricted contexts

From: Tony Skjellum <[email-masked]>
Date: Tue, 2 Feb 93 11:14:40 CST

Ladies/Gentlemen:

The notion of context implementation for efficiency should not drive 
it to be a highly limited field.  It is true than if there are only a 
few contexts, then they could be moved to hardware support.  I think that
large software will have many hundreds of contexts, and that this resource
should be less limited.   I dislike the notion that hardware-specific
details creep into the standard.  For instance, CM-5 could/does have 8
hardware contexts of messages, at a low level, but these are not really
published to the user at all.

The issue of whether one or many queues are supported is completely
separate, and can be addressed separately.  Separate queues weaken
the partial ordering guaranteee of a message passing system; ie, that messages
are received in pairwise-preserved order.  Hence, they have been avoided
thus far in the work I have done.  However, there is nothing in principle
wrong with letting an implementation disperse messages as they come in
based on context.  The best partial screening for messages is highly 
application dependent.  Perhaps some type of adaptive hashing could be
used internal to strong implementations, but it should not be required.
For instance, independent of context support totally, adaptive hashing
on type/sender could be incorporated to existing systems.

I do not think it too inefficient to test 64 bits instead of 32 bits for
typing.  In practice, there are much more serious overheads in a system.
The notion that we have full push-down message stacks, is an example of
this.  Active messages systems are highly context oriented.  They make
the context bigger (eg, an address on the destination machine) rather
than smaller.   One can see that there is a basic unity between 
message selection and context support... contexts help to route messages
to the right execution part of a destination process.

Registry is very important, because it guarantees that code (be it user
or other library code) will cooperate reasonably well, given the message
resource.  This type of registry is accepted for file systems, for instance,
where we accept that FORTRAN unit number is a bad way to program.  Unix
file descriptors provide insulation between different parts of a program.
Same idea for contexts.

Is a context associated with a group?  Well, I hope so, but enforcing this
is less important.  Groups are very important in and of themselves, and to
have guarantee that a context is available in a group is very useful.  It
also makes sense to me that a loosely synchronous registry by a group of
processes to get a context is a good idea.  

For instance, a big group of processes initially has a context.  It can
ask for more contexts, and pinch off subgroups, establishing an MPMD
processing environment.  Overlap is permitted.

Smaller groups of processes, starting with their own contexts would need a
way to union into bigger groups.  A mechanism for this is needed.  This
direction is important for scalability, for fault tolerance, and for
dynamicism in processing on large collections of distributed or parallel
processors.  For instance, homogeneous clusters could union into a heterogeneous
collection, and the resulting communication structure would provide a
tree-like (at least two-level) access to messaging, which could also be
useful for optimizing performance of global communication in a heterogeneous
setting.

Other ideas?

- Tony Skjellum

---

From: [email-masked] (James Cownie)
Date: Tue, 2 Feb 93 18:10:37 GMT

> it to be a highly limited field.  
I'd like the additional cost of contexts to be small. I'd also like it
NOT to impact people who don't use contexts. Both of these drive me in
the direction of the sort of implementation I was proposing. This is
easy provided there are relatively few contexts, hard if they're as
anarchic as tags.

> It is true that if there are only a 
> few contexts, then they could be moved to hardware support.  
Yes, but not the reason for my proposal. I have no desire (or need) to
do this. 

> I think that
> should be less limited.   
I can't imagine why you need another 10 bits of context when you
already have 32 of tag. What are you going to use the context for ?

> I dislike the notion that hardware-specific
I agree entirely. My proposal is not based on any specific hardware
implementation. (My hardware has a small processor in it which can
execute C code and run comms processor threads in a remote user space
without requiring any main processor intervention, but I'm not asking
for that in the standard !)

> thus far in the work I have done.  
True, I didn't see this as a problem, since I thought that messages in
different contexts could reasonably be unordered with respect to each
other. (This was based on my view of what contexts are for, as
explained in the intro to my proposal, maybe you have a different use
for them in mind ?)

> However, there is nothing in principle
Of course all of these things are possible, and all add to the
baseline latency. I was hoping to reduce this, not increase it.

> this.
I haven't seen any proposal in the MPI context which doesn't take this
approach, and since I'm not trying to rewrite the whole thing...

> file descriptors provide insulation between different parts of a program.
Exactly. That's why my context proposal is based on the file
descriptor model.

> processes to get a context is a good idea.  
In my model a group can request a context. It does not have one a
priori. (Maybe it doesn't need one since it can use one which the
relevant processes already have).

-- Jim
James Cownie 
Meiko Limited			Meiko Inc.
650 Aztec West			Reservoir Place
Bristol BS12 4SD		1601 Trapelo Road
England				Waltham
				MA 02154

Phone : +44 454 616171		+1 617 890 7676
FAX   : +44 454 618188		+1 617 890 5042
E-Mail: [email-masked]   or    [email-masked]