Hello Viktoras,
GraphComputer supports both BSP and Dirty BSP, but NOT full asynchrony. Dirty BSP is a memory efficient BSP model where you don't keep two vectors around --- the properties in the previous BSP cycle and the properties in the current BSP cycle. Thus, you don't have full isolation between the two steps --- but the gain is you only have one vector of memory.
In terms of the actor model, you can think of GraphComputer as implementing the actor model where each vertex is a "thread/actor/agent" and you are propagating messages between them. The flow for a particular vertex is as such:
1. Read all incoming messages.
2. Do something with those messages.
3. Update your local state in some way (e.g. setProperty())
4. Send messages to other vertices (both adjacent and arbitrary recipients supported).
1-4 is repeated over and over and over until a termination point is reached. The model above is not new and has been around for some time with Pregel, HAMA, Giraph, and Faunus. There are various tweaks to the model that we think are neat:
1. If you are sending messages to neighbors in a single machine implementation, you can greatly reduce the amount of messages sent using a "blackboard" behind the scenes.
2. However, global message passing (arbitrary receivers) is possible like in the classic message passing systems.
2. While the vertex is the message's receiver, you can address a vertex, its properties, its edges, or its edge properties.
3. It uses a fluent interface to build VertexPrograms and will have a nice look and feel in the Gremlin3 REPL.
Finally, there are two ways to think of this as "the actor model." When you look at this pattern from the Gremlin perspective you start to see the messages as the actors and the graph as the communication substrate. In Gremlin OLAP, the messages (i.e. gremlins) are complex objects that store state and move about the graph according to the rule system dictated by the GremlinPipeline. In this way, you can decide where you want the computation to be represented --- in the vertex or in the message. The Gremlin perspective comes from "swarm computing" where you think of your messages as having the computing logic, not the VertexProgram.
HTH,
Marko.