Communication and Synchronization Abstractions

Appeared in Volume 7/4, November 1994

Keywords: parallelism.


From: pereira@alta.research.att.com (Fernando Pereira)
11th June 1994

I see all sorts of ungainly assemblies of ill-fitting components being passed on as 'real world software engineering.' Anytime one of those contraptions is stressed at all, it collapses into deadlocks, race conditions or loss of synchronization. The problem is that the communication and synchronization abstractions in these systems are character streams, sockets, signals and select(2), which may be manageable by top systems programmers (when the planets are aligned just right), but just the wrong level of description for the interactions in complex applications. But without a shared abstract model of complex data, higher-level communication abstractions are impossible. And without a shared, higher-level model of computation, improved synchronization abstractions are impossible. Finally, without a shared language for interfaces and (parameterized) modules, code reuse is extremely difficult.

Some of those issues are being addressed at the theoretical and experimental level in the logic and functional programming communities, but somehow the investment in dealing with them in practical ways is much less than in more esoteric issues of programming language design with much less potential payoff.

To be blunt, the current tools for interactive, distributed multicomponent applications are comparable for the tasks they are trying to address to what assembly language was for algorithmic and systems programming in the 1950s/60s. As then, the field is controlled by a small priesthood of wizards jealous of their arcane knowledge and status. As the door to programming was open by high-level programming languages, the door to coordinated computing is waiting to be blown open by appropriate coordination languages. This opportunity and challenge should not be missed by the logic and functional programming communities. It is their chance to make an impact not only at the margins, but at the very center of the future of computing.


From: dc@debara.dcs.qmw.ac.uk (Daniel Cohen)
11th June 1994

Nicely put. Part of the problem is in convincing people that these are problems at all. The concurrent logic programming languages have some nice answers in this area (particularly with respect to communication and synchronization abstractions) but when I worked for the people selling Strand it proved very hard to convince people that the problems the language overcame were significant problems. It seems the commercial world is always readier to adopt quick and dirty fixes than clean abstract solutions.


From: andrew@cee.hw.ac.uk (Andrew Dinn)
13th June 1994

It is true that writing a distributed/parallel application in Strand (substitute favourite PLP) is easier than writing it in e.g. Fortran with message passing primitives. However, there is reason for people to be wary of a canned solution like Strand and instead to adopt the toolkit approach Fernando appears to deprecate. Strand simplifies some problems but not others (e.g. how do you `tune' the comms so it overlaps the computation :-). Fernando's argument seems to be that we need to identify the right abstractions, implement them once and then adopt them universally. Trouble is that there is no unique set of abstractions appropriate for all cases. Needs vary and so accordingly should the programming abstractions which one adopts. Most existing solutions are likely to build in unwanted features.

The virtue of a toolkit is that one has a variety of tools with which to build languages and libraries which bootstrap one from the implementation domain to the application domain, enabling a clear, effective and efficient implementation to be produced (that this bootstrap process has to be thought through and performed for every new application is for me a personal truism. I don't believe the problem is with the toolkit based approach per se but rather with the sloppy way the tools are strung together and the shoddyness of some of the tools.


From: dc@debara.dcs.qmw.ac.uk (Daniel Cohen)
13th June 1994

Ok. But are you saying that a concurrent logic language is not appropriate as the communications and synchronisation component of such a toolset? I'm not sure if you're describing Strand as a all-purpose tool. I never thought of it that way; on the contrary, to me Strand seemed quite minimalistic. In particular, I believe the power of the Strand approach in such tasks derives largely from the fact that there is just a single mechanism at the heart of it.

Of course, this way lies PCN and such like - designed for use as glues to stick program components together. Is it inevitable that languages honed purely for "glue" roles must lose their logical interpretation and simplicity? I'd like to think not, but Strand wasn't quite there, and I've yet to see a major improvement (Janus?)


From: pereira@alta.research.att.com (Fernando Pereira)
14th June 1994

I did not intend to deprecate the toolkit approach. What I was deprecating were the current ways of coordinating those tools. What I was advocating were coordination languages/mechanisms based on good communication, synchronization and encapsulation abstractions that would allow us to describe the interfaces of tools and how we wish to coordinate their use. A particular component may well have its own policies with respect to overlapping local and remote computation, but it should be able to specify in a language-independent way how it wants to communicate with other components. Libraries like OLE and OpenDoc do something in that direction, but as far as I know they are not well-integrated in a broader model of coordination that addresses some of the related issues I mentioned.

Andrew Dinn wrote:

I don't believe the problem is with the toolkit based approach per se but rather with the sloppy way the tools are strung together and the shoddyness of some of the tools.

Exactly. But what I have to see yet are significant proposals to overcome those sloppy and shoddy practices, which I contend are anchored in a lack of theoretical understanding of coordination.


From: andrew@cee.hw.ac.uk (Andrew Dinn)
14th June 1994

Daniel Cohen wrote:

But are you saying that a concurrent logic language is not appropriate as the communications & synchronisation component of such a toolset?

No, I think I was saying that there is no such thing as an all-purpose tool and that the attempt to produce one is misguided.

Strand is indeed very simple and does provide a fairly useful communications & synchronisation component for many purposes.

As far as database programming is concerned, I think the best type of glue is procedural as in e.g. Glue/Nail (the concept, not the implementation) Compare it with say LDL++ which completely messes up the logic in order to enable updates. The important thing is to integrate the procedural and logic components well. I'm down the end of a list of authors on a paper in the next VLDB on exactly this subject - look out for `An Effective DOOD Through Language Integration'.


From: geoff@coral.cs.jcu.edu.au (Geoff Sutcliffe)
14th June 1994

I've used my Prolog-D-Linda system to build parallel/distributed Prolog applications, almost painlessly. And it's very easy to communicate with processes written in _any_ language, through the tuple space. But I agree, the semantics are probably quite horrible.