This PR adds support for parallelism in method tasks on Mahler.
While expanding a method during plan search, the planner will default to expanding methods in parallel branches. Before adding the result of the method back to the plan, the evaluation will check for conflicts on parallel branches. This is done by inspecting the list of changes, calculated as a
JSON patch, and looking for intersecting changes between any branches. If a conflict is found, then the planner will re-do the expansion of the method in sequence.
Calling byTwo in parallel results in a conflict, as we are modifying the same part of the state. Thus the planner treats the method as a sequential operation, resulting in the following plan
This PR also updates utilities for testing that plans correspond to an expected outcome. For instance, for the latter example above, we may want to test that the resulting plan corresponds with our expectations. On testing, we could do the following
// On top of the test file
import { plan, branch, fork, stringify } from 'maher/testing';
// On the test suite
const result = planner.findPlan({ a: 0, b: 0 }, { a: 3, b: 2 });
expect(stringify(result)).to.deep.equal(
plan()
.fork(branch('a + 1'), branch('b + 1'))
.fork(branch('a + 1'), branch('b + 1'))
.action('a + 1')
.end(),
);
Creates a string representation of a plan with two forks, each fork with two branches updating values a and b respectively
The string representation will return a string like the following, that should make it easier to compare the plans visually
+ ~ - a + 1
~ - b + 1
+ ~ - a + 1
~ - b + 1
- a + 1
Where - indicates an action, + indicates a fork and ~ indicates a branch of the fork
Note that despite the amount of changes, this is an initial PR to enable parallelism. Conflict detection and backtracking when parallelism fails is still rudimentary, and this is still heavily lacking documentation
This PR adds support for parallelism in method tasks on Mahler.
While expanding a method during plan search, the planner will default to expanding methods in parallel branches. Before adding the result of the method back to the plan, the evaluation will check for conflicts on parallel branches. This is done by inspecting the list of changes, calculated as a JSON patch, and looking for intersecting changes between any branches. If a conflict is found, then the planner will re-do the expansion of the method in sequence.
For example, given the following code
Calling
byTwo
in parallel results in a conflict, as we are modifying the same part of the state. Thus the planner treats the method as a sequential operation, resulting in the following planNow let's take the following definition.
Counters
a
andb
can be safely increased in parallel, which results in the following expansionThis PR also updates utilities for testing that plans correspond to an expected outcome. For instance, for the latter example above, we may want to test that the resulting plan corresponds with our expectations. On testing, we could do the following
Where
Creates a string representation of a plan with two forks, each fork with two branches updating values
a
andb
respectivelyThe string representation will return a string like the following, that should make it easier to compare the plans visually
Where
-
indicates an action,+
indicates a fork and~
indicates a branch of the forkNote that despite the amount of changes, this is an initial PR to enable parallelism. Conflict detection and backtracking when parallelism fails is still rudimentary, and this is still heavily lacking documentation
Change-type: minor