ForkNode

Forks a single control flow into multiple concurrent ones.

Data-only Gyre graphs are always implicitly concurrent: there is no ordering relation between data-only nodes other than the one implied by their def-use chains. When a node also requires control flow, expressing the fact that it is concurrent with respect to another (i.e. one operation does not necessarily need to happen before the other) is impossible in a classic CFG. Fork nodes are Gyre's way to work around this limitation by signaling explicit concurrency.

More...

@mnemonic("fork")

struct ForkNode {

InEdge control;

OutEdge[] threads;

static err_t initialize(ForkNode* self, uint n);

static void dispose(ForkNode* self);

bool opEquals(const(ForkNode) rhs);

hash_t toHash();

inout(InEdge)* opIndex(InEdge.ID slot);

OutEdgeIterator!Callable outEdges [@property getter];

InEdgeIterator!Callable inEdges [@property getter];

}

Members

Functions

opEquals bool opEquals(const(ForkNode) rhs): Equivalence check.
opIndex inout(InEdge)* opIndex(InEdge.ID slot): See Node.opIndex.
toHash hash_t toHash(): Semantic hash.

Properties

inEdges InEdgeIterator!Callable inEdges [@property getter]: Provides an iterator over this node's in-edges.
outEdges OutEdgeIterator!Callable outEdges [@property getter]: Provides an iterator over this node's out-edges.

Static functions

dispose void dispose(ForkNode* self): Frees all resources allocated by this node and sets it to an uninitialized state.
initialize err_t initialize(ForkNode* self, uint n): Initializes a fork node, must be later disposed.

Variables

control InEdge control;: Incoming single control flow.
threads OutEdge[] threads;: At least two concurrent control flows resulting from this fork.

Mixed In Members

From `mixin NodeInheritance`

opPostMove void opPostMove(const(This) old): Post-move adjusts in-edge slots' owner pointer.

Detailed Description

Fork nodes tell the compiler "the following subprograms have no ordering constraints between each other". RULE: It is an error for any of the resulting control flows to make direct use of a value produced in another one of its sibling 'threads'. Still, every event which happens before a fork also happens before the events of its resulting control flows. Merging multiple concurrent flows back together can be done at a join.

TODO: fork semantics are unclear w.r.t. progress. e.g.: when one thread blocks (and it could be waiting for a message from another sibling thread), do all other threads block as well? (in that case, we could have starvation; if other threads don't block, they need to be independently scheduled, which in turn requires help from the OS, etc)