Valued Lessons

I've learned. I'll share.

June 27, 2008

My Experience with Message Passing Concurrency

I'm working on a peer-to-peer file synchronization program. It's really concurrent and distributed, and it's forced me to learn a thing or two about the concurrency models that we use as programmers. Over the past few years, I've tried both the shared-state model common to C, C++, Java, C#, Python, etc, and the message-passing model unique to Erlang and Scala. In my experience, the message-passing model (aka Actor Model) is far superior to the shared-state model for writing distributed applications. After having used both extensively, I'd go so far as to say that for distributed programming, shared-state concurrency is upside down and backwards.

Here's my informal proof that message-passing concurrency is necessary in a distributed system:

  1. Since the system in distributed, real shared state is impossible.
  2. The only way for the distributed components of an application to communicate is by sending a message from one to another.
  3. Everything else is an abstraction on top of message passing.
HTTP is an abstraction on top of message-passing. AJAX is an abstraction on top of HTTP on top of message-passing. XML-RPC is an abstraction on top of HTTP on top of message-passing. SOAP is an abstraction on top of an abstraction on top of an abstraction on top of HTTP on top of message-passing. Any RPC mechanism is an abstraction on top of message-passing. SQL queries to a remote database are an abstraction on top of message-passing. CORBA is a nasty, tangled mess on top of a foundation of message-passing.

See a pattern?

Not only are all of these abstractions, but they are leaky abstractions. Just about all RPC (Remote Procedure Call) frameworks try to pretend that remote objects or local. But the facade is impossible to keep from leaking. Calls to a remote object might fail or take arbitrarily long. If you want to make the same call to two different remote nodes, those calls must be made synchronously and sequentially; in order to call them in parallel on the remote nodes, they most be called in parallel on the local node. If a call to a remote node triggers a call back to the local node, which may trigger a call to a third node, you end up with a huge spaghetti mess of calls and threads.

I've been down that road. It wasn't pretty. There is a better way.

I think AJAX has opened our eyes a bit. It's a lot closer to message-passing than it is to RPC. In a REST architecture, you "send" messages by POSTing to a URL and you "receive" messages by GETing a URL. All messages are clearly local copies that were serialized and deserialized from the remote data. There isn't any leaky abstraction of data or classes pretending to be in two places at once. Data, timeouts, and failures are in your face and you have to deal with them. So, AJAX is a lot less leaky.

But AJAX is far from perfect. I can't help but think of the Greenspun's Tenth Rule of Programming with a twist on distributed programming: "Any sufficiently complicated distributed platform contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a message-passing system (Erlang)". Once you get message-passing in your head, you can't help but think of AJAX in that way.

I've been down a better road. It was much more pleasant.

About six months ago, I rewrote major portions of our application with message-passing concurrency. I took a long time. It was tricky. It hurt my head. But it worked. It's a success. It's capable of things that the shared-state system could never do.

Having done it, I can emphatically say that if I could start all over, I would go with message-passing. Most of the work was building the infrastructure and wrapping my head around a new way of thinking. But now that I've done both of those, I've paid the costs and I'm reaping the rewards. We're moving the application in directions that would have been nearly in possible with the old concurrency model.

In my experience, message-passing concurrency is the best way to write distributed applications. But it isn't an easy road to go down. Support for it just isn't there in most programming languages and environments. So far, Erlang has been the pioneer. I would humbly agree that the way I've implemented message-passing in Python, compared to Erlang, looks like an ad-hoc, bug-ridden half-implementation. But for various reasons, I can't use Erlang. I'm hoping for someone to create Erlang++ or E# or Eython or something that combines the concurrency model of Erlang with a modern programming language. Until then, I'll just keep on cobbling together what I can onto the programming language I happen to be using.

More on that in another article.

Labels: , , , , , ,

7 comments:

  1. I've been working on actors in dynamic languages (currently Ruby and Python) for a couple of months, pretty much for the same reasons you do. I also envy the features and maturity of Erlang but I need actors in things that can't be reinvisioned in Erlang.

    For what it's worth:
    http://dramatis.mischance.net.
    ReplyDelete
  2. Wow. You on a very nice website with very nice documentation. It's obvious that you've spent some time on it. In comparison, my support and documentation is quite pathetic :). I also like the name name "dramatis".

    Your implementation of the Actor Model obviously has one huge difference with mine: yours implements synchronous message passing and mine implements asyncrhronous message passing. Since I'm working in a very distributed environment, asynchrounous message passing is MUCH, MUCH better for me. In fact, synchronous message passing has most of the same pitfalls as RPC and I don't think it's very suitable for disrtributed programming at all.

    But I think it's great that you're starting a whole project with nice support and documentation. The more popular and supported message passing becomes, the better.
    ReplyDelete
  3. Nice article Peter. It is good to see that someone has gone through much the same process as I have with message-passing. My dive into Erlang was largely inspired by the power I saw in AJAX.

    For a Python-like syntax and coding style on the Erlang VM check out Reia.

    However, after the initial weirdness shock with the syntax I found I actually preferred Erlang's native syntax to that of Java, Groovy, Ruby or Python. I found its pattern-matching and recursion support extremely useful when I was building a Mercurial SVN integration. I had initially tried to write the integration in Groovy and found the once familiar mutability of variables and types vs pattern-matching foreign, risky and lacking in expressive power.
    ReplyDelete
  4. Dramatis does have async calls; in fact, like Erlang gen_server, everything is async, just with a little support for making it easy to do rpc-like calls where that is the right semantics. Really it's continuation-passing, but a lot of people seem to be afraid of continuations. They're actually pretty important (though often hideable) in distributed programming.

    My experience has been that there are lots of cases in actor programs where you want to do these "pseudo-blocking" calls. You can always do them more explicitly, by having the target of the call send a message back. This is basically manual continuation passing and I've had to do it sometimes in the past. But, at least for me, I've found it so common, e.g., asking another actor for status, that if it's hard to express, it gets very aggravating very quickly. My code where I had to do this got ugly very fast and I've been hoping with dramatis, I'd not go down that path again.

    I agree fully that, used exclusively, rpcs aren't a very good programming model. They're the same old recursion model which doesn't provide any help in communicating between objects. But as far as I've seen, "blocking calls" are still needed in data-flow-like models in order to reflect data dependencies. (Actually, futures should work for that too, which I've been playing with with dramatis.)

    A simple example of this is the auction example, which I grabbed from Scala by Example. There's really nothing for a bidder to do until it hears the result of it's bid, so at least for that one exchange, CPS/RPC feels pretty natural, even in a distributed environment.
    ReplyDelete
  5. Instead of thinking of things as "RPC", I think of it as "make a request and wait for a reply". That way, you can do things like make multiple requests in parallel, choose what to do if the reply doesn't come in a certain amount of time, or keep doing other work until the reply. "RPC" is just one kind of possible request/reply pattern that allows only one request, hides timeouts, and doesn't allow work until the reply comes.

    One pattern for RPC that I do like that Erlang seems to use is to spawn another actor/process just for waiting for the reply. The main requester can then continue work, or make many requests, etc. But, obviously, we'd need to implement threadless actors for that to have any chance of working.
    ReplyDelete
  6. I also find the "RPC" label a lot less than a perfect fit. I've just had a hard time coming up with something that also isn't flawed. I try to avoid using "wait" in descriptions, because actors don't wait, exactly.

    Certainly any "rpc" in an actor system isn't going to be the same as traditional rpc's, a la ONC. How actor rpcs (see, there I go again ...) differ from ONC-like rpcs is an area I find pretty interesting. Erlang's OTP implements one pattern, with certain tradeoffs, dramatis a different pattern, etc.

    Is there an example where Erlang spawns an actor to wait for a reply? I can't remember any that highlight that in particular.

    I do find it interesting that Erlang gen_server "call" does pretty much block everything else. That feels kinda inconvenient. If you go back to low-level Erlang examples, there are plenty of cases where something like a status message would be allowed everywhere. But I don't think you can implement that with gen_server (because it implements the receive loop).

    Dramatis (which implements patterns from both Erlang and OTP) by default has that same behavior: when you make an rpc-like call, you become sensitive only to the response from that call. But it also allows the actor to specify that certain patterns will always be allowed, allowing, for example, status messages at any time, which is useful to me. I guess this means that all Dramatis actors are threadless: the threads are actually owned by the scheduler and are allocated to tasks to execute individual method calls as appropriate.

    Great discussion. I'm hoping for more of these: cross-fertilization, etc. I've set up a google group http://groups.google.com/group/actor-talk to maybe give people a place to collaborate?
    ReplyDelete
  7. How do you find Python-stackless then?

    Eve Online MMORPG use it heavily. I don't know about server, but for client-side for sure.
    ReplyDelete

Subscribe to: Post Comments (Atom)

Blog Archive

Labels

Google Analytics