The ReadCSV Action is “injecting” new rows (that are read from the Hard Drive) into the graph. Each time Anatella calls the ReadCSV Action, it does the following:
1.Look at the internal Row-Buffer of the Action:
a.If the Row-buffer is empty:
i.Read a bunch of data (typically 1 MB) from the Hard Drive and copy into the Row-Buffer (And, optionally, de-compress the binary data into usable data).
ii.Select the first row in the buffer.
b.If the Row-Buffer is not empty:
Select the next row in the buffer
2.“Inject” the selected row into the Anatella graph and remove it from the Row-Buffer.
The ReadCSV Actions is using a synchronous (i.e. blocking) I/O algorithm (See the section 22.214.171.124. about asynchronous I/O algorithms). This means that, while Anatella is occupied reading some data from the Hard Drive (when it copies 1MB of data from Hard Drive to main RAM memory), it “freezes” the whole Multithreaded Section that contains the ReadCSV Actions. To avoid freezing the whole data-transformation-graph, it’s a good idea to isolate the ReadCSV Action in a separate Section (thus using a Multithread Action).
The same remark applies to all the other “Input Action” that are based on a simple synchronous (i.e. blocking) I/O algorithm: the SASReader Action, the ODBCReader Action, etc. For example, you’ll often have:
In this way, when the ReadCSV Action “freezes” (because it’s waiting for the Hard Drive), it only blocks its own Multithreaded-Section but the rest of the transformation graph (i.e. the other Sections) can still continue to run (without any interruption), using the rows that are inside the FIFO-row-buffer of the Multithread Action, just next to it. Of course, if it freezes for too long (i.e. if the Hard Drive or the database is very slow), then the the FIFO-row-buffer of the Multithread Action empties out and, once again, the whole data-processing stops (this is sometime referred, in technical terms, as a “Pipeline Stall”). This happens very often with the ODBCReader Action because the databases systems are usually very slow compared to Anatella Graphs: More precisely: Databases have usually some difficulties to “deliver” the rows at the high-speed required by Anatella for optimal execution speed. In such common situation, one way to reach high-processing speed is to run “in parallel” different SQL extractions, in different Multithreaded Sections.
For example, this is not very efficient (despite the fact that it includes several Multithread Actions):
The above graph will run the 3 database extractions one after the other and the processing speed will most likely be quite slow because of “Pipeline Stalls”. The following graph (that runs the 3 database extractions “in parallel”) is a better solution:
You can think of the Multithread Action with several input pins as the “multithreaded” equivalent of the standard GlobalRunFlag. The GlobalRunFlag executes the graph sequentially:
First, the GlobalRunFlag runs all the Actions connected to the pin 0.
Once it’s finished, the GlobalRunFlag runs all the Actions connected to the pin 1,
Once it’s finished, the GlobalRunFlag runs all the Actions connected to the pin 2,
Once it’s finished, the GlobalRunFlag runs all the Actions connected to the pin 3, etc.
In opposition, the Multithread Action executes the graph in parallel. As soon as you run the Graph (e.g. as soon as you pressed F5), all the Action connected to the Multithread Action start running at the same time.
You can still have some control on the order in which the Actions are executed using the “Synchronization” option of the Multithread Action.