I've been using the word 'composition' in the mathematical sense. Relational composition involves taking relations as input and producing a relation as output. Functional composition involves taking functions as input and producing a function as output.
Actors composition involves taking actors as input and producing an actor as output. Note the singular on the output. To achieve composition in actors model requires introducing a non-trivial extra element: a serializer. Properly, it really should also involve some extra analysis to ensure that processing is complete prior to any final reply. That is, when one virtual actor is composed of multiple actors, there is risk of producing long-lived 'message loops' within the actor's definition that continue concurrently with processing future replies. Whether you see this issue as a 'problem' is really up to you. When I pursued actors model, I considered actor composition pretty much irrelevant, and instead focused on abstraction and composition of 'actor configurations' to the point of dropping the message-serialization in favor of transactions. But there are plenty more issues to be found once you start dealing with (a) interactions that take multiple messages to complete (e.g. queries followed by updates), (b) multiple client actors sharing a service actor, aka shared resources, (c) a single client actor attempting to coordinate independent service actors, and (d) various combinations of (a,b,c). Concurrency being mediated by message delivery doesn't help much when interesting interactions require multiple messages to complete. Further, some state is often involved in any such interaction - i.e. to allow behavior to depend upon prior messages. Coordination of multiple service actors will always involve multiple messages, multiple responses, and challenges from partial-failure: a rejection from one service half way through coordinating with another. And consider the general case of this: composable coordination, where the actors in the coordination might themselves be performing coordination of multiple service actors. The notion that there is no 'shared mutable state' isn't true in any relevant sense. If ever two actors share a reference to a third, and the latter's behavior is a function of messages received, and they might interleave communications, then you effectively have shared mutable state. All the normal issues of race-conditions and interference will apply. This becomes problematic when interactions require dependence on a message history. I suspect you'll find these scenarios more common once you start considering all the ramifications of concurrent, rather than sequential, composition. You might not see the issues, however, if you focus on 'actors in-the-very-small' - i.e. down at the level of single client to single service interactions rather than at the many-to-many level. On Tue, Jun 22, 2010 at 8:28 PM, Dale Schumacher <[email protected]> wrote: > The example of implementing a queue (using a serializer) is definitely > part of a meta-circular definition of actor behavior. Serializers are > one of the critical mechanisms identified by Hewitt, et. al. long ago. > I believe that maintaining multiple virtual configurations of actors > provides another important way to partition actor systems. > > In either case, I don't see the problem in composing actors, > especially if they have limited interactions. Since concurrency is > mediated by message delivery, and message handling generally > represents small finite amounts of computation, independent actor > behaviors are interleaved at a very fine granularity. And they can't > interfere with each other because they don't have shared mutable > state. > > Of course, when working with traditional threaded systems, the cost of > context switching encourages us to do a lot more work between context > switches. I think the key to effective actor implementations is a > dramatically lower context switching cost, which I have achieved in my > prototype. > > The big mental shift in working with actors is to think in terms of > concurrent, rather than sequential, composition. When I start > describing the meta-circular definition of Humus, in terms of actors, > the inherent pervasive fine-grained concurrency will be more clearly > exposed. > > -- > send mail : [email protected] > subscribe : [email protected] > unsubscribe : [email protected] > home page : http://groups.google.com/group/pilud > Note: reply address is set to the list -- no need to "reply all" > _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
