This blog is - mainly - about the development of libcppa (C++ actor library). But why should we use actors in C++ instead of a signal / slot implementation?
Why bother about "yet another way of decoupling"?
Well, the actor model is all about concurrency. Concurrency by design rather than concurrency by implementation. Mutexes, semaphores and thread primitives are the wrong level of abstraction for programming many-core systems. Think about machines with 20 or more cores (this is the future and there's no way to get the free lunch back!). Writing both thread-safe and scalable code using low-level primitives is challenging and error-prone. You should not think about how to make use of those cores. You should use a level of abstraction that allows your runtime system to make use of as many cores as possible. This is the point of libcppa: raise the level of abstraction in C++. Furthermore, the actor model unifies concurrency and distribution. Since actors communicate by network-transparent, asynchronous message passing, one can freely distribute actors among any number of machines.
Of course, the actor model is not the only high level abstraction for concurrency. There is libdispatch, (software) transactional memory and agents or many other approaches such as concurrent channels (e.g. in googles go) or intel blocks. However, the actor model is the only computation model that applies to both concurrency and distribution.
Available real-world applications of the actor model (such as Erlang or Scala libraries) have shown that the actor model leads to scalable applications with a (usually) good software design consisting of small, easy-to-understand and easy-to-test software components.
The actor model is very easy to understand and to explain. Everyone knows what a message is and how a mailbox works. All you have to explain is the syntax to get a message from actor Alice to actor Bob and how Bob could read and compute messages from its mailbox. And there is no reason why C++ should not provide an implementation of the actor model to ease development of concurrent and distributed systems.
Hey, I am interested in C++ Actors models. One thing I'm curious about your implementation is whether it supports interprocess messaging. Can I have Actors distributed across multiple machines?
ReplyDeleteI've updated the blog post to emphasize the distribution component and network transparency of libcppa. The documentation will get an update soon to cover distribution and some pitfalls (mainly due to the very nature of C++, e.g., no general solution for serialization).
DeleteYes, communication between Actors is network transparent. But C++ has some limitations compared to Erlang, e.g. you can't spawn Actors on another node in the network.
ReplyDeleteThe function pair you need to connect two libcppa-apps is publish/remote_actor. You call publish() on the "server"-side with an actor_ptr and the network port. The "client" calls remote_actor(host, port) and gets an actor_ptr as result on success.
The TCP connection handling, message serialization, etc. is all done by libcppa. TCP Multicast support (and group communication in general) is also on its way. :)
Sounds nice! Is the code ready to be tested? Is there any documentation planned?
ReplyDeleteI can't promise I'll have time to give it a whirl soon, but it's in the back of my mind now.
Hi, documentation - and blog posts - are on my ToDo list. The features are implemented; have a look at the test__remote_actor.cpp from the unit tests for an usage example.
ReplyDeleteThe unit tests works, but if you find new bugs during your tests, please create Issues at github. :)
Hi Dominik,
ReplyDeleteYou may be interested to check the Microsoft Casablanca: actors, rest services, http server/client, json (http://msdn.microsoft.com/en-us/devlabs/casablanca). The implementation is Windows specific now, but I understand that the vision is to have cross-platform (standard or de-facto) libraries for these stuff, even if they won't port it, of course. Thus the API interface is quite clean. As it is an incubation project, your experience in the domain may be valuable.
Regards,
Tavi.