“Classic” Actor Semantic Model

Tags: , , , ,

This description of the Actor Model is intended to build intuition about how the model works using reasonably precise terms. However, it is not a formal mathematical description. We are focusing on the so-called “classic” model [1], which is treated with much more formality in earlier literature [2] [3]. Overview A configuration is a set […]

Continue reading » No comments

Producer/Consumer Rate-Matching

Tags: , , , , , , , , , , , , , , ,

Flow control is a critical feature in a network of asynchronous communicating processes. Our fanciful exploration of a yak-shaving barber’s shop provided us with patterns we can apply to more general problems. The bounded-buffer mechanism is a generalization of our barber’s waiting room. It mediates between producers and consumers, matching the rate of production with […]

Continue reading » No comments

Implementing Actors in Kernel

Tags: , , , , , , , , , , ,

Now is the time we come full-circle in our exploration of Kernel/Scheme/LISP and show how Actors can be implemented on this foundation. This should dispel the notion that Actors are just functions/procedures. Sure, when an Actor receives a message you could say that the message is “applied” to the Actor’s current behavior. In that sense, […]

Continue reading » No comments

Erlang-style Mailboxes

Tags: , , , , , ,

One significant difference between message-passing in Erlang and the pure Actor Model is the Erlang concept of mailboxes. Actors don’t have mailboxes, at least not in the sense that they can be queried. Messages simply arrive at some non-deterministic time after they are asynchronously sent, invoking the current behavior of the actor. However, in Erlang, […]

Continue reading » No comments

In-Order Message Delivery

Tags: , , , , , ,

The Actor Model explicitly avoids placing constraints on message delivery order beyond causality [1]. Messages may not be delivered before the message which caused them to be sent. In other words, time can’t flow backward. Beyond that, messages arrive in a non-deterministic order. This can sometimes have surprising consequences. Two messages sent in sequence from […]

Continue reading » 1 Comment

Actors Make Better Observers

Tags: , , , , , , , , , ,

The Observer pattern causes temporal coupling in systems with synchronous message passing. This can lead to failure in Object-Oriented systems. Asynchronous messaging avoids the pitfalls. Actor-based implementations more accurately realize the original intent of the pattern. The intent of the Observer pattern is to “define a one-to-many dependency between objects so that when one object […]

Continue reading » 3 Comments

Message Passing, part 2 – Object-Oriented Method Invocation

Tags: , , , , , , ,

This is part two of an article exploring what we mean when we say “message-passing”. Part one described how synchronous rendezvous can be expressed with actors. Part two describes an actor implementation of object-oriented method invocation. For Object-Oriented developers from the Smalltalk tradition, message-passing involves a dynamic method lookup, invocation of that method with the […]

Continue reading » 2 Comments

Message Passing, part 1 – Synchronous Rendezvous

Tags: , , , , , , ,

What do we mean when we say “message-passing”. For Object-Oriented developers from the Smalltalk tradition, message-passing involves a dynamic method lookup, invocation of that method with the target object as an implicit parameter, and return of a result object. By contrast, message-passing in synchronous communication models (such as Ï€-calculus) involves “rendezvous” between sender and receiver, […]

Continue reading » 3 Comments

Deconstructing the Actor Model

Tags: , , , , , , ,

The Actor Model of Computation, as defined by Carl Hewitt [1] and elaborated by Gul Agha [2], defines three primitive operations. These operations are “Send”, “Create” and “Become”. The “Send” operation transmits an asynchronous message to a known receiver. The “Create” operation constructs a new actor with a specified initial behavior. The “Become” operation defines […]

Continue reading » 7 Comments