Threading is prevalent in computing although, as a user of computer applications, you have no need to be aware of what threads are and what they can do for you.  However, Absyntax cannot mask the concept of threading.  This is because the way your project manages and handles threads will have a fundamental bearing on its behaviour.

 

Think of a thread as a worm of activity: its tail is fixed at its point of origin and it extends itself along connections and through features.  When your project starts running, a thread enters through the project's Entry input.  Then, depending on how you have configured your entry point, the thread will either be routed along each connection in turn or it will spawn a new thread for each connection.  Thereafter, the same rule applies: whenever a thread emerges from a feature it will either be routed along each connection in turn or it will spawn a new thread for each connection, depending on how the output has been configured.  Finally, when a thread has no more connections to serve, it disappears.

 

If the same thread is required to serve two connections in turn (i.e. synchronously), it will only serve the second connection once it has finished with the first.  To understand what this means in practice, consider the following diagram.  This illustrates seven features, labelled A through G, and the connections between them.  The connection numbers indicate the order in which they are to be served by a single thread.  Suppose that all outputs are configured to operate synchronously.

 

 

 

 

A thread passing out of feature A is required to serve connections to features B and G.  Firstly it visits B, which does some work with it before dispatching it to C.  Feature C does not trigger any outputs and so, once it has finished with the thread, the thread is free to serve the next connection of B's output.

 

 

 

 

Next, the thread visits feature D which does some work with it before dispatching it to E.

 

 

 

 

Feature E does not trigger any outputs and so, once it has finished with the thread, the thread is free to serve the next connection of D's output, which takes the thread on to feature F.

 

 

 

 

 

Feature F does not trigger any outputs, so finally the thread winds its way back to the next connection of A's output, which takes it on to feature G.  You will need to rely on the descriptions and documentation for a feature and its inputs in order to determine the circumstances in which a particular output is triggered.