Emphasising asynchrony does not mean for example we should assume a communication medium with unlimited bandwidth (and certainly not with zero latency!). And we wish to have different ways to analyse such a medium --- they may be modelled as "ether" separate from processes or formalised as a collection of processes. We may need a queuing model on some occasions. But these will come later and as needed: at this point we do not mind these aspects, we solely want computation to be asynchronous.
But what does it mean to be "asynchronous"? One may define the notion informally thus:
the potential for each distributed process to be able to work following its own local clock, as far as there is no need to be fed data from other programs and synchronise.First of all, it is about the potential: and we want that potential as a key element embedded in the model. Second, "local clock" etc is not too good a metaphor: anyway it gives us some idea, that a local program can be left to compute on its own as much as possible. Third it says there is some need to exchange data and synchronise --- but not saying how. Not saying it is to compute a function. If it is computing a function --- well that is one way. But there can be other ways. And there are.
Why do we know? We have known about it from the study of process algebras which are about the universe of concurrent, communicating behaviours. And especially because of our study of the pi-calculus which miraculously captures a very rich variety of interactional behaviours, and, as interactions, a wide variety of computational behaviours, in its tiny syntax. And this wide variety --- for studying which one can use many ideas, such as separation which Palamidessi once used in her beautiful and celebrated result. So we know. There are many kinds of behaviours, all couched in a small calculus of name passing.
What is further fascinating to me ---- and this is the first thing which fascinated me in theory of computing and why I started to work on science of computing seriously --- is that this calculus has an asynchronous version, and it turns out to be a minimal meaningful kernel of this calculus.
This point was observed based on the work by Milner/Parrow/Walker in 1989, and later by Milner in 1990, and let's face it I also contributed in my small way and, as I wrote, this incidental observation fascinated me so irresistibly. Later I found Gerald Boudol discovered the same calculus concurrently (and completely independently), in the context of his Chemical Abstract Machine.
Coming back to behaviours --- so I can tell you we have a huge universe of computational behaviours, and many of these things are meaningful, certainly realisable, and they are not always computing functions.
But that is not enough. That fact I knew for long and of course had been known before me by others. What we needed to know in addition is what it means for behaviours to be functions. Then we know the ground --- by knowing the figure. Since if so we know there is more than the figure --- now the ground can be a figure in its own right.
A series of studies have clarified this, starting from an embedding of functions in processes by Milner, and I do not quote them since there are so many, but let me say studies on logic and games (as we call them in our community) play a fundamental role here. This line of studies is still a very rich field and will continue to be.
So --- to make a long story short --- there are many kinds of interactional behaviours which go beyond what compute functions. And for all of them asynchrony is a foundation, a starting point, even though they may constrain asynchrony in diverse ways. So what we see is messages going hither and thither asynchronously. It is wrong to assume order-preservation in the delivery of these messages a priori --- which does not mean we cannot have it based on some mechanism, but can you think of a Turing machine which embeds a notion of objects and classes? Or data structures? Or even procedures... That will make a bad model, a good execution model should have two properties: being simple, and being very simple. And perhaps the third: being very very simple up to the point it almost (or perhaps completely) flat. I know this does not sound anyway informative (I know that) so I promise --- if you are interested --- that we shall come back to this point later. For now it suffices to say that we start from asynchronous exchange of data which may not preserve order. And we do not go into further details here, since probably the party ain't started yet and it is too early to start eating (but is about to, I believe).
For now, we have mentioned several very basic properties. Incidentally the characteristics I observed above are close to what Matthew Rawings once told me --- or declared to me --- as what should be an abstract model for financial networks.
I am not related to money so much (which surely makes me deal with money issues critically sometimes). Neither in my life nor in my profession I feel intimate about how international financial networks carry trillions of dollars each day, that's a different world, anyway it is a huge network, billions of messages going hither and thither each day, distributed all over the world, and this cannot work synchronously, can it? It cannot be order-preserving, can it? So this is something I do not understand in terms of amount of money involved but can surely understand some basic aspects of it in terms of computation involved.
So this story is after all (partly but honestly) about scribble: "One of its primary application areas of this language is modelling of financial protocols." By the way Gary just wrote to me about identities in interactions --- which are a little different from asynchronously operating localities at the abstraction level we are exploring now, but are closely related, and are certainly one of the key subjects for scribble. That is another topic, we shall surely reach there in near future: for now, we need to think a little more about hardware, to cultivate our understanding of this "a" word further.
kohei
