Intercontext communication

Hello,

One of the challenges of developing concurrent software, is how to communicate between different contexts. I use the word context as a placeholder for thread, process, or machine. In most desktop application software I have seen, shared data accessed synchronously seems to be the preferred way to communicate. Data access from multiple contexts must be synchronous in order to be safe. In addition to synchronous access of shared data, you can communicate via some kind of channel or port, which allows one context to send data, and another to receive it.

All this is old news. There is plenty of information online which explains thread safe programming, shared memory, BSD sockets and other such things. My point is that all the various mechanisms are there to serve one underlying purpose: communication. Ultimately, whichever mechanism you choose, what you really want to do is communicate some information. Granted, efficiency, capability, and convenience greatly influence your choices, but from a system design perspective, they are hardly relevant. When you design a system at a high level, using say UML, it's unlikely that you will have a model element for each mutex or socket you use.

With this in mind, now think about object oriented programming. Hmm... the wheels in my head are turning. Can we abstract the very concept of communication into an interface? I prefer to reserve judgement, I don't think I am prepared to follow this line of reasoning to its limits. Taking a step backwards, and trying to fit this into my audio processing engine, what consequences does this perspective have on my design? Clearly I have a concurrent application on my hands, as there is one or more realtime audio processing contexts, and one or more control contexts. Well suddenly I have a lot more freedom from the constraints of specific communication methods. Whereas mutex based communication is only available within a single process, or shared memory is only available on a single machine, the concept of communication is not bound by any particular constraints (semioticians, lets not nitpick).

In practice, this means that my code must use some kind of polymorphic communication system, most likely a class hierarchy, but the payback for this abstraction is potentially huge. Various application contexts can reside virtually anywhere, as long as a mechanism exists which can facilitate communication. Theoretically, a context may exist anywhere in space or time, communicating via wormhole, or some other theoretical or yet unimagined mechanism.

Now this is all very dramatic, but hopefully it illustrates how much freedom you can gain with a little abstraction. Now I am off to design a (simple) abstract communication library so that my audio processing system can be free as a (time traveling, teleporting) bird.