Execution modes

Signal/Collect supports different execution modes. The execution mode determines what kind of guarantees about the execution order of the signal/collect operations a user gets. When you want to use the console server, you should use the interactive execution mode.

#Synchronous execution A synchronous computation consists of alternating parallel signaling/collecting phases for vertices. Phase transitions are globally synchronized, which guarantees that all vertices are in the same phase at the same time. One signaling phase followed by one collecting phase is referred to as a computation step. This execution mode is closely related to the Bulk Synchronous Parallel (BSP) model and Pregel.

In order to start a computation using the synchronous execution mode we call the execute method on our graph, with the parameter of an execution configuration, for which we already specified the ExecutionMode:

val graph = GraphBuilder.build
val execConfig = ExecutionConfiguration.withExecutionMode(ExecutionMode.Synchronous)
graph.execute(execConfig)

#Asynchronous execution In an asynchronous computation the framework does not give any guarantees about the order in which signal/collect operations get executed. This allows workers to operate without central synchronisation, which can improve performance. Some algorithms also have better convergence when run asynchronously, because it can prevent oscillations. This execution mode is closely related to the Actor Model. The default execution mode of Signal/Collect is to start with one synchronous signaling step followed by an asynchronous execution, we refer to this mode as OptimizedAsynchronousExecutionMode.

How to start a computation using the default execution mode:

val graph = GraphBuilder.build
graph.execute

How to start a computation using the pure asynchronous execution mode:

val graph = GraphBuilder.build
val execConfig = ExecutionConfiguration.withExecutionMode(ExecutionMode.PureAsynchronous)
graph.execute(execConfig)

There is also a continuous asynchronous execution mode, but apart from not blocking, but immediately returning and from not using termination detection (see Algorithm Termination), it is equivalent to the pure asynchronous execution mode:

val graph = GraphBuilder.build
val execConfig = ExecutionConfiguration.withExecutionMode(ExecutionMode.ContinuousAsynchronous)
graph.execute(execConfig)

---

Previous: Signal/Collect Operations

Next: Interacting with the Graph

Interactive Execution

The interactive execution mode enables you to do arbitrary partial steps or full signal/collect steps, however, it requires you to use the console server. The console server starts a web server so you can investigate your computation in the web browser. It adds a graph view to explore nodes and vertices, and a resource view to inspect the infrastructure while a computation is performing. However, the console server will not start by default, it has to be explicitly configured in your code. Here is an example which does not yet start the console server:

val graph = GraphBuilder.build
// adding vertices and edges ...
graph.execute

This will create a graph and (after adding vertices and edges) execute the computation. In order to start the console server we need to add the withConsole(boolean[, port]) method. It expects a boolean telling whether or not to start. An optional port number can be defined to specify on which port you would like to start the console server. If no port is given, the program will try to start on port 8080. When that port is already busy, it will simply try the next one. If needed, it will try up to the port number of 8179. Here is a code example with a fixed port number.

val graph = GraphBuilder.withConsole(true, 8090).build
// adding vertices and edges ...
graph.execute(ExecutionConfiguration.withExecutionMode(ExecutionMode.Interactive))

As you can see, we also added the new ExecutionConfiguration. This will block the computation (i.e. it won't proceed) until the user explicitly wants to perform a partial step, a whole signal/collect step or even proceed until the computation has converged. The control over this computation control can be specified directly on the console server.