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:
- Since the system in distributed, real shared state is impossible.
- The only way for the distributed components of an application to communicate is by sending a message from one to another.
- Everything else is an abstraction on top 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.
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.
ReplyDeleteFor what it's worth:
http://dramatis.mischance.net.
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".
ReplyDeleteYour 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.
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.
ReplyDeleteFor 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.
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.
ReplyDeleteMy 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.
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.
ReplyDeleteOne 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.
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.
ReplyDeleteCertainly 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?
How do you find Python-stackless then?
ReplyDeleteEve Online MMORPG use it heavily. I don't know about server, but for client-side for sure.
خدمات النظافة بالدمام لابد ان تقدمها شركة لديها ثقة في اتمام خدمات النظافة المنزلية لان النظافة العاية لا تعطي النتيجة الفعالة التي تتم بواسطة شركة تنظيف بالدمام متخصصة لانها تهتم بكل شئ داخل المباني فلدينا شركة تنظيف فلل بالدمام تكون متخصصة في نظافة الفلل المفروشة والمستعملة واعطائها الرونق الجمالي الخاص بها لدينا شركة تنظيف شقق بالدمام متخصصة في اعمال نظافة الشقق المنزلية وشقق المكاتب والمعارض بواسطة الادوات والمواد اللازمة لعمل ذلك لدينا تخصصتنا في اعمالنا التي ترضي العميل وتخلصة من الحشرات الصغيرة التي تسبب ازعاج كبير للاسرة من خلال شركة مكافحة حشرات بالدمام التي لديها معدتها وموادها لعمل ذلك كما يوجد متخصص ايضا للقضاء علي الحشرات من خلال التواصل مع شركة رش مبيدات بالدمام التي تنتهيك من كل الحشرات المنزلية كما نعمل معا للواصل اليك كل الخدمات المنزلية من خلال خدمة الاثاث بواسطة افضل شركة نقل اثاث بالدمام والتعامل معها سوف يصل الي منزلك الجيد بدون اي تعب
ReplyDeleteكما يوجد خدمتنا الاخري التي يمكنك البحث عنها م والاستفادة منها
شركة تنظيف بالقطيف
شركة تنظيف بالجبيل
شركة تنظيف بالاحساء
now present in your city
ReplyDeleteAccording to Bain report, "23% of companies surveyed have clear strategies for using analytics effectively". Therefore, it is necessary that you have successfully identified the data and insights are significant for your business. data science course syllabus
ReplyDeleteChuyên vé máy bay Aivivu, tham khảo
ReplyDeletemua ve may bay di my
cách đăng ký chuyến bay từ mỹ về việt nam
lịch bay từ canada về việt nam
ve may bay vietnam airline tu han quoc ve viet nam
cool, please guidance so that I can create a blog like yours
ReplyDeleteWow! Such an amazing and helpful post this is. I really really love it. It's so good and so awesome. I am just amazed. I hope that you continue to do your work like this in the future also.
ReplyDeletebest data science institute in hyderabad
thank you for the information provided, we are waiting for the next info
ReplyDeleteI love this. It is soo informative. Are you also searching for cheap assignment writing service uk we are the best solution for you. We are best known for delivering the best services to students without having to break the bank
ReplyDelete
ReplyDeleteExcellent content ,Thanks for sharing this .,
Leanpitch provides online training in CSPO, everyone can use it wisely.
CSPO certification online
Certified scrum product owner
Excellent content ,Thanks for sharing this .,Scrum master certiification Chennai
ReplyDeleteCSM certiification Chennai
Excellent content ,Thanks for sharing this .
ReplyDeleteScrum master certiification Hyderabad
CSM certification in Hyderabad
Excellent content ,Thanks for sharing this .,
ReplyDeleteOnline teaching tools
Virtual classroom setup
Excellent content ,Thanks for sharing this .,
ReplyDeleteSkills for online teachers
Free teaching tools
ReplyDeleteExcellent content ,Thanks for sharing this .,
Online teaching platform
Online teaching tool
Such a nice read. Thanks for sharing! https://truckpartsuperstore.ca/collections/westin
ReplyDeleteI just wanted to say that I am new to blogging and thoroughly loved your post. Certainly, I will bookmark your website. You definitely have excellent post material. Thank you for exchanging the fantastic domain post with us.
ReplyDeletedivorce lawyer consultation cost
The programming language in IT plays an important role in the industry. Today modern era only technology can lead. You share valuable information in this great blog post. Now it's time to avail Car Services in Orlando for more information.
ReplyDeleteExplore the complexities of parallel processing, the successes and failures of thread-to-thread synchronization, and the paradigm shift this concurrency paradigm can bring about. Come explore the captivating story of how messages are woven into the code to create a symphony of parallel execution. Your ability to transform everyday subjects into amazing journeys is something I find genuinely admirable. Words have the ability to change people, whether you're talking about deep philosophical ideas or the complexities of everyday life.
ReplyDelete