"I have a mind like a steel... uh... thingy." Patrick Logan's weblog.

Search This Blog

Loading...

Monday, September 03, 2007

Rob Pike on Concurrency and Message passing in Newsqueak

Rob Pike and Luca Cardelli created a simple, concurrent language called Squeak (not to be confused with Squeak Smalltalk) for simplifying programming user interfaces. Pike then turned that into Newsqueak, a more complete programming language. (See "Squinting at Power Series", (pdf)).

Newsqueak has processes like Erlang. But instead of an implicit inbox and outbox per process, Newsqueak has channels as first-class types. All channels are half-duplex, synchronous communicating, well, "channels", as in C.A.R. Hoare's Communicating Sequential Processes. Newsqueak also has only immutable data values, although it does have true variables rather than single-assignment. (Not sure yet how that interacts with concurrent processes running closures over variables lexically known to each process.)

And so Newsqueak can be used to do Erlang-like programming and vice versa, using processes/channels/functions or processes/pids/functions to implement something like the other's mechanisms.

Although Newsqueak does not have the distribution mechanisms or the failure mechanisms of Erlang. And rather than using pattern matching over all the messages in a process inbox, in Newsqueak a process might use something like one channel per pattern or encode all the possible patterns into a structured type passed over a single channel.

Russ Cox has an overview of CSP in the context of Bell Labs where Newsqueak was developed and then led to other interesting things.

Pike is now at Google and not too long ago recorded an interesting and well-done Tech Talk on Newsqueak and concurrent, message passing programming generally...

  • Define components as interfaces with all data flow and sharing done as communication over channels.
  • The interface is a type; implementations of that interface just honor the protocol.
  • Composition is linear in complexity of design but superlinear in expressibility. (The opposite of composition of state machines.) Interleaving is free. Compose interfaces, not state machines.
  • Parallelism is not the point, but falls out for free. Networking and remote execution are not the point, but also can fall out (although not quite for free).

...Concurrent processes with message passing can be a powerful model for programming, whether the problem is intrinsically parallel (server design) or not (power series)...

The expressiveness - notation - is important.

Update: Ehud linked here from Lambda the Ultimate, and that thread has several comments of its own.

7 comments:

gvwilson said...

I used Occam (the transputer implementation of CSP) very heavily in the 1980s and early 1990s, and eventually started referring to channels as "the return of the GOTO", since in any moderately complex application, you spent a lot of time wondering, "If I put bytes in *here*, who will they go to?" Addressable actors and/or tuple spaces both felt much more scalable (in the coding sense).

Mathias said...

Wouldn't "the return of the COMEFROM" been more appropriate?

Sorry, couldn't resist.

Patrick Logan said...

I suspect I'd rather start with asynchronous messaging and inboxes as persistent as their processes rather than start with unbuffered, synchronous messaging.

And I suspect that very soon I would want to implement some higher-order coordination mechanisms.

David Sitsky said...

I've written a bunch of message-passing programs in PVM/MPI, and as Greg has indicated, it does become complicated quite quickly.

I am currently implementing a parallel application using activemq, an implementation of JMS (Java Messaging Service), which has a very nice programming model (named queues, publish/subscribe) and also has optional message persistence for fault tolerance.

The jury is still out as to how well it is working in my application, but so far, I think it is quite effective.

Michael Arnoldus said...

David - please check out AMQP as a replacement for activemq ...

Samuel A. Falvo II said...

I really hate to burst your bubble here, but the concept of a variable as defined in functional programming circles (that is, single-assignment semantics) is the more correct interpretation. A variable is an input to a function. It's "variable" because its precise value can change from function computation to function computation. But, during a computation, they cannot change.

Patrick Logan said...

"I really hate to burst your bubble..."

Not sure what bubble you're referring to. Newsqueak does *not* have single assignment. That is a problem with newsqueak. I've not read enough yet to understand what the behavior of imperative variable assignment is in newsqueak.

I prefer Erlang's simpler and yet capable single assignment.

Also your description of variables "changing" is inaccurate. In functional languages, there are different bindings of a variable to values. Any given binding does not change.

New bindings are created, bindings do not change. That is the key to Erlang's single assignment simplicity.

Blog Archive

About Me

Portland, Oregon, United States
I'm usually writing from my favorite location on the planet, the pacific northwest of the u.s. I write for myself only and unless otherwise specified my posts here should not be taken as representing an official position of my employer. Contact me at my gee mail account, username patrickdlogan.