Representing parallel operations in flowcharts

user3419556 picture user3419556 · Apr 18, 2015 · Viewed 8.8k times · Source

I need to do a flowchart of a hydraulic system featuring a temperature regulation module. However, temperature regulation is only activated during one part of the cycle. During this part, the system continues to perform other operations.

I want to represent that in my flowchart diagram. I need a way to tell when the parallel algorithm begins and when it ends within the main flowchart. How do I do that ?

Answer

Ira Baxter picture Ira Baxter · Apr 18, 2015

Add two new flowchart nodes/operators fork and join.

Fork takes one control flow coming in, and produces two going out, similar to the diamond decision node in regular flowcharts. Unlike the decision node, the fork node passes control to both of its children, meaning that "parallel execution starts here".

Join takes two control flows in, and produces one control flow out. It means, "wait for execution on both input branches to complete, then pass control to the output branch". This means "parallel execution stops here".

Now your flowchart can have serial and parallel sections; you can even have the parallel sections generate additional, nested parallelism.

Now you need a graphical representation of fork and join.

We represent the control flow graph of real computer programs with essentially a flowchart ("actions" and "decisions"). Because of the similarity of "fork" to "decision" (one input, two outputs) we chose to draw "fork" as an upward facing triangle (one input at the top, two outputs at the triangle base endpoints), and "join" as a downward facing triangle, with two inputs at the triangle base endpoints and one output at the peak of the downward facing triangle.

You can see automatically generated examples of this for C and COBOL programs. You might not think these contain parallelism... but, in fact, the langauge semantics of many languages is often unspecified, allowing parallel execution in effect (C function arguments according to the standard can be evaluated in arbitrary order, for example). We model this nondeterminism as "parallelism" because the net effect is the same.

People building industrial control software also need to express this. They simply split the control flow line going from one flow graph item to another. See Sequential function charts in this document.

The most general "control flow" notation I know are Colored Petri Nets. These can model not just control flow, but data flow, synchronization, and arithmetic, which means you can model systems with very complex flows. You can model a regular flowchart directly with a CPN. CPNs also generalize finite state machines. What that means for programmers, is that if you don't know about CPNs, you should learn about these now. And you discover that "flowcharts" (as CPNs) are now useful again in discussing systems whose parts run asynchronously.