Subject: Re: My notes from the Rain meeting
From: Matthai Philipose (matthai@cs.washington.edu)
Date: Thu Jan 31 2002 - 13:53:55 PST
An additional direction that may be interesting is that of providing an
interface and run-time support for controlling the use of underlying
resources by the application. This has to do with moving code and data
around (with varying degree of application-level input as to how to do
it) during the life of the program/system in ways that satisfies the
requirement of the application. At some level, this looks like the
scheduling problem in compilers:
+ How do we represent (perhaps in an programmer-extensible way), the
underlying resources available to the computation e.g. network
bandwidth, latency, connectivity, power, computing speeds,
administrative privileges? The parallel for conventional compilers is
the machine model used by a static scheduler which has things like
latencies for various operations, number of registers and function
units, etc.
+ How do we represent the resource requirements of a program? In the
conventional world, this corresponds to the CFG/PDG of a program that
needs to be scheduled, i.e. the functional units for each instruction
are the resources, and the dependence edges between the instructions are
the constraints expressing requirements on how they are used.
+ Given an application with certain resource requirements, how do we map
it onto the underyling fabric? This corresponds to the conventional
scheduling problem, but potentially much richer because constraints are
richer, and may have to solved online.
+ What's the programming-language level interface to these resources to
expose to the application programmer? This is different from
conventional compilers, since machine level details are not (modulo the
old "register" keywords) exposed to the user, and you don't get
scheduling/register allocation hints/requirements from users. However, I
think it's pretty certain that for apps of this kind, application-level
programmers would really want to have some say on resource requirements
for their programs.
This is traditionally an area that is the bread-and-butter of
operating-systems folk, but in this era of blurring lines between OS's
and run-time systems, and the increasing relevance of programming
language research in operating systems ;-), there's no reason for us not
to take a bite out of it. The key question is whether integrating
resource scheduling with language-level support gives any extra mileage
in this domain.
Matthai
Keunwoo Lee wrote:
> I think it would be productive to start a discussion, both in email and in
> meetings, about what we took away from the Rain meeting. Here are my
> mental notes; maybe this will start a thread. I've already mentioned the
> basics of these to some of you.
>
> ~k
>
>
> + Communicating independent processes, with guaranteed delivery, where
> services are names that can be passed around the system, is very close to
> the pi calculus!
>
> + One important difference: they do not appear to have the notion
> of "broadcast on a channel"; every process effectively has a unique
> "in" channel that it listens on. So, in fact, the rain system can
> be viewed as a restricted system of processes in the pi calculus.
>
> + The reliability and in-order guarantees match closely with the
> synchronous version of the pi calculus, not the asynchronous
> variant used by e.g. Pierce et al. for Pict.
>
>
> + The XML-based message passing leads me to believe that some of the
> machinery developed for XDuce could be used in a domain-specific
> programming language. Programmers really want to pattern-match over XML
> trees and then execute code. The "natural" way that I imagine programming
> in this paradigm is something like the following:
>
> component foo =
> <msg name="bar"> * </msgname> => ...
> <othermsg> <tag id="x" /> * </othermsg> => ...
>
> This looks a lot like the case statement in XDuce (except they use square
> brackets instead of matched tags). I expect, though, that the Rain
> programmers want
>
> + ordinary OO code for most things that are not components,
> + inheritance among components
>
> neither of which are supported by XDuce, which is ML-like, of course.
> XDuce also provides some strong guarantees that will probably have to be
> sacrificed due to versioning of messages etc.
>
>
> + XML is not just an artifact of wanting SOAP/.NET interoperability.
> Fundamentally, the idea of passing semistructured data enables the
> evolution of messages. Old versions of a piece of software can extract
> only those pieces that they understand, and punt on the rest.
> Semistructured-ness can also be used to "mixin" pieces of data, e.g. for
> audit trails. It's possible that these properties could be added in using
> an object model not tied to semistructured data, but it's not obvious to
> me how to do it nicely.
>
>
> + What are the properties that one might want to prove/infer over programs
> written in Rain? There's a lot, but here's my current list of things that
> might be interesting:
>
> + "Will all messages will be understood by their recipients?"
>
> This is the standard interface-matching problem, except there's
> probably versioning issues, plus the semistructured data issue.
>
> + "What is the minimal environment of services that this component
> needs in order to operate?"
>
> I have a PDA in my pocket, and I walk into a room and boot it up.
> I want to know which components are going to work, so the software
> should figure this out and present it to me. Presumably there's
> some sort of service discovery process; you would like to discover
> only the services that you need, rather than overloading the room
> by asking it to send every available service. Even better would
> be incremental levels of discovery, supporting increasing amounts
> of functionality.
>
> + "Given that this group of components share some secrets, can I
> verify that some things are never transmitted unencrypted?"
>
> It seems like this is an application for the security calculus
> work by Abadi et al.
>
>
> + When a component wants to wait for multiple related messages to arrive,
> perhaps something in the vein of the C# concurrency stuff presented by
> Cardelli et al. at FOOL would be nice. Match over a set of messages, and
> then execute the body.
>
> + Easy optimization: execute some parts of the body eagerly, before
> all the pieces arrive, by using data dependence.
>
> + Elaboration: produce specialized versions of eager execution to
> handle different orders of arrival.
>
>
> + In one of the code fragments Stebbi showed us, he used a "continuation"
> object to wait for the reply to a message and execute some code. This is
> an obvious opportunity for language support... forking N continuations to
> wait for N replies should be easy from the programmer's point of view.
>
> Of course, once you want to receive a message, you get back into the XML
> pattern matching issues. You would like to be able to wait for an
> ordinary XML message, i.e. you do not want to force the remote component
> to send you some magic "continuation cookie", because the remote component
> should not have to know that the result is being used as part of a
> continuation. So, continuations may have to cooperate with top-level
> matches to determine who handles a message.
>
>
> _______________________________________________
> Cecil mailing list
> Cecil@cs.washington.edu
> http://majordomo.cs.washington.edu/mailman/listinfo/cecil
>
_______________________________________________
Cecil mailing list
Cecil@cs.washington.edu
http://majordomo.cs.washington.edu/mailman/listinfo/cecil
This archive was generated by hypermail 2b25 : Thu Jan 31 2002 - 13:50:12 PST