las3_pub / predictable_parallel_patterns

Now end users only have to #include<pls/dataflow/dataflow.h> to use all parts of the API. We split dataflow out from the general algorithms header, as it is a rather big API and could bloat the users namespace/includes.

This makes the programming model a full dataflow implementation, as it allows for branching and recursion.

Recursion works by using a function node, calling the graph again. We separated an graph invocation form an function invocation within an graph, making the graph only handle one concern.

Now all expressions in the assert macro are enclosed in parentheses, avoiding issues.

We separated the structure (input-output flow) from the rest of the architecture and reworked some template programming to have better access to the types required at compile time.

The data can now flow into a graph, follow its path on inptus/outputs and be fetched from the graph after execution.
Currently graphs are executed synchronous.

The data can now flow into a graph, follow its path on inptus/outputs and be fetched from the graph after execution.
Currently graphs are executed synchronous.

We need some tricks in template programming to have a clean user facing API while internally using our classes with more capabilities.

We need some tricks in template programming to have a clean user facing API while internally using our classes with more capabilities.

This is the base building block for creating the actual dataflow functions and networks, as their main functionality is having data flow through connected nodes.

Threads must be joined on scheduler termination and tasks must be pushed onto the stack to allow better memory management.

This removes boost as an dependency from our code and makes our project
again only dependent on C++11 compilers (no external dependency).

Now all algorithms are used without the parallel pre-/suffix and the for_each method has an specialization for integer ranges.

This seems to be only possible with two different function names, as variadic arguments and default arguments wont work together.

See the comment in the source. This race should actually not be important, but we fix it anyways for now to make the CI happy.

This should have been fine without the atomic property (as it is only a single writer and multiple readers to a single bit). Nevertheless we fixed the 'race' to remove a warning in the thread sanitizer.