Implementing language features using Actors has reached the point
where the actor primitives themselves can be described meta-circularly. http://bit.ly/9KfHLI ============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org |
Administrator
|
The Actor pattern certainly seems to map on to Agents in modeling.
I'm fascinated by the lack of globals. I wonder how that is handled? Is there a Factory that can hold the global information needed by Actors? If all this can have reasonable performance, especially in a distributed system, it'd be a good model for some of the distributed ABM ideas we've been considering. Oddly enough, we've thought of Javascript as a good language to use. Its everywhere, becoming so pervasive on the server side that one company, Joyent, is converting to it for its hosting services. That would lead us to use it on the client, the server, and via JSON, as the messaging between client/server. Indeed, we might go to a symmetric model where the client/server become the same, both being servers (async listening) and responding (sending messages). One issue is the identity of the Actors involved. We'd need something like a universal id for each so that they could find each other world wide. Possibly a URL? -- Owen On Nov 20, 2010, at 6:30 AM, Dale Schumacher wrote: > Implementing language features using Actors has reached the point > where the actor primitives themselves can be described > meta-circularly. > > http://bit.ly/9KfHLI > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > lectures, archives, unsubscribe, maps at http://www.friam.org ============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org |
On Sat, Nov 20, 2010 at 10:19 AM, Owen Densmore <[hidden email]> wrote:
> The Actor pattern certainly seems to map on to Agents in modeling. There's certainly a lot of similarity between Actors and Agents, especially at the conceptual level. My understanding of Agents (and I'm sure there are many on this list with a better understanding than I) is that they are part of a simulation and thus have a critical emphasis on modeling time. Often discrete "generations" or "ticks" are used as the time model, batching up a group of related computations which define the value of the next discrete state of the system as a function of the current state. A colleague and I are working on a genetic-algorithm solution to the traveling salesman problem, modeled with actors, which is specifically designed to use a continuous, rather than generational, model of time. Actors are built on a causal-chain model of time. Events can "cause" other events to occur and state changes are "caused" by the occurrence of an event. Since all messages are asynchronous, and there is an arbitrary delay between sending a message and it being received, the only restriction on message ordering is that a message must be sent before it can be received. Actors representing "clocks" can be introduced into the system and produce periodic events from which other computations can be triggered. If these events are driven from an external source, such as periodic timer interrupts, then the rate at which they occur can correspond to "real" time. > I'm fascinated by the lack of globals. I wonder how that is handled? Is there a Factory that can hold the global information needed by Actors? "Globals" are a relative concept. They are simply identifiers which represent the context common to a "whole" system/configuration. Configurations can be nested, where identifiers in an "outer" context appear "global" to the "inner" context(s). If a group of actors required access to a common resource, such as the definition of a console "println" actor, then an identifier for the common resource would be bound in a scope which enclosed the definitions of all the actors in the group. Any state which changes over time is modeled with an actor. Identifiers are bound to pure immutable values. An actor's identity (which is required in order to send it a message) is a value, and may be bound to identifiers and passed in messages (which are also values). So there is no direct access to shared mutable state, only shared contexts which provide identifiers for immutable values, but those values can identify actors whose behavior changes over time. > If all this can have reasonable performance, especially in a distributed system, it'd be a good model for some of the distributed ABM ideas we've been considering. Modest PC hardware can support MILLIONS of concurrent actors in an efficient implementation. Erlang is a reasonably efficient implementation which also supports network distribution of actors/processes. > Oddly enough, we've thought of Javascript as a good language to use. Its everywhere, becoming so pervasive on the server side that one company, Joyent, is converting to it for its hosting services. That would lead us to use it on the client, the server, and via JSON, as the messaging between client/server. Indeed, we might go to a symmetric model where the client/server become the same, both being servers (async listening) and responding (sending messages). At a much larger granularity, actor-based thinking can be mapped onto hybrid client/server network nodes. The "node.js" project is doing very interesting things with JavaScript-based creation of asynchronous servers. > One issue is the identity of the Actors involved. We'd need something like a universal id for each so that they could find each other world wide. Possibly a URL? Management and representation of actor identities is a key issue is creating large-scale distributed systems. URI schemes certainly seem to have some applicability here. However, note that not all actors need to be "universally" addressable. Some actors will only interact with a small group of collaborators, often within a single address space, and possibly only exist for a very short period of time. Others may well represent long-lived "well known" services, and may be implemented by whole configurations of smaller actors communicated through a network end-point "facade". Network addressable "proxies" can also be dynamically created when/if an actor wants to provide access to a "remote" peer. ============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org |
Free forum by Nabble | Edit this page |