Hoare, Communicating Sequential Processes, and JCSP

[Luke Gorrie]

Scott Lystig Fritchie <fritchie@REDACTED> writes:

> Many thanks to Luke Gorrie for pointing out Hoare's _Communicating
> Sequential Processes_ (CSP).  That book is hard to find below US$70.
> I found a copy via Amazon.com for US$50, but the seller had to give me
> a refund when he discovered that his inventory system lied.  :-(  I
> managed to find another just yesterday for US$42.  :-)  Hopefully this
> one will be able to deliver.

Glad to hear someone bit! To me that's an amazing book, and really
sums up doing "Erlang as it's supposed to be", by my interpretation at
least.

Another oldie that I seriously enjoyed recently was _The Architecture
of Concurrent Programs_ by Brinch-Hansen. It was published in 1977 and
describes Concurrent Pascal and three actual tiny special-purpose
operating systems written in it. Concurrent Pascal uses Monitors for
communication and synchronization, but the programming style is much
closer to Erlang than Java. As a long time Java guy, I found it very
interesting to see what the original idea of monitors actually
was. The whole approach has a very Wirth-like philosophy (I think Joe
would like it if he hasn't already read it.)

There are lots of copies of that on www.bookfinder.com from as little
as $8.90 incase someone's mad enough to take my recommendation :-)

> Following the link to the JCSP project,
> http://www.cs.ukc.ac.uk/projects/ofa/jcsp/, led to enlightenment for a
> kind.  Peter Welch's (long!) slide presentations have
> interesting stuff.  Including the following (typos are mine(**)):
> 
> 	// "Objects Considered Harmful"
> 	class Thingie {
> 		private:
> 			int count;
> 		public:
> 			method1() {
> 				count = 42;
> 				thing.func();
> 				// What is the value of count here??
> 				// 42?  43?  Something else?
> 			}
> 			method2() {
> 				count++;
> 			}
> 	}
> 
> You don't know if the thing object's func() method might end up
> calling (directly or indirectly) Thingie's method2().  Java's
> "synchronized" monitor locks won't help.  "This lack of ability to
> reason locally about private fields is strangely familiar. In the bad
> old days, free use of global variables led us into exactly the same
> mess. Structured programming led us out of that mire. Is object
> orientation taking us back in?"

Spot on! As he says, you don't even need concurrency, since some other
object (or this object itself in a subclass) might be messing around
with all the current state in unprecitable ways.

What's really funky is just how little is certain in object-oriented
code. Take this Java method for example:

  boolean add_and_check(Vector v, Object o) {
      v.add(o);
      return v.contains(o);
  }

Ignoring threading, this is not guaranteed to return true, since the
implementation of the 'o' object may have overridden the equals()
method in a broken way, so that when the vector checks o.equals(o) it
returns false. This is pretty scary if you are trying to write code
that will be correct for all inputs, and I think that in general you
can make just about any piece of java code blow up unpredictably by
feeding it a sufficiently stupid input. This seems to be the pattern
that the java-based webbrowser security exploits have followed.

That said, I think the main part of the OO mindset is to embrace this
as a feature instead of a bug. But still, I'm glad that in Erlang I
don't have to worry about e.g. accidentally passing Mnesia a broken
object that will destroy my databases, like circular lists as keys or
something :-). Erlang seems very good at keeping bugs in one part of
the program from unpredictably blowing up other seemingly unrelated
parts.

Cheers,
Luke