Parallel Loops != Multiple Threads

[Daklu]

Lately I've been reading up on data flow languages in general and Labview's execution system and discovered I have been thinking about things all wrong. Chunks of code without data dependencies can execute in parallel, so over time I have come to associate that parallelism as meaning multiple OS threads are used. It turns out that's not the case. Multiple threads may be used, but are not necessarily used.

So that leads to my question. If they're not threads, what do we call each arbitrary unit of code that is free from external data flow dependencies?

We often refer to parallel "loops," but parallelism isn't always contained in a loop.

Labview documentation refers to groups of sequential operations as "clumps." Those are artifacts of the compiler, not the dev environment, so I'm not sure that's a good name either.

"Branch" is a likely candidate. We talk about branching wires all the time. We don't typically talk about a branch as a unit of execution. Plus "branch" tends to refer to what you see on the bd, not an arbitrary chunk of data flow. In the diagram it is obvious SubVI1 is a branch, SubVI2 is a branch, and SubVI3 + SubVI4 is a branch. (Assuming none of the sub vis obtain external data from references.) Notice that SubVI1 + SubVI2 + Add primitive is also a branch, but the term "branch" doesn't seem (to me) to naturally apply to that group of code.

Thoughts? Ideas?

[mje]

I recall the term task was used quite a bit back in the day, but this might be due to the same reason as we throw the term thread around so willy-nilly today (before multithreading was really an option, the feature to talk about was multitasking)...

I in fact still use the term task, but I frankly have forgotten the details as how LabVIEW's internal scheduling compares the multitasking operations of an OS. I'm not sure if the term is technically correct when applying it to a LabVIEW context.

[jdunham]

Lately I've been reading up on data flow languages in general and Labview's execution system and discovered I have been thinking about things all wrong. Chunks of code without data dependencies can execute in parallel, so over time I have come to associate that parallelism as meaning multiple OS threads are used. It turns out that's not the case. Multiple threads may be used, but are not necessarily used.

So that leads to my question. If they're not threads, what do we call each arbitrary unit of code that is free from external data flow dependencies?

Around here we call them "LabVIEW threads". I think it's a reasonable name because they have the same purpose and behavior as OS threads, even if the implementation is hidden in the LV execution engine. Even though it's much easier to implement a LabVIEW thread than an OS thread in many other languages, that's just one of the cool features of LabVIEW, it's not a reason to change the name.

As a related example, you might have some operation that "reads data from disk file". But if you have a modern OS, it often occurs that the data is actually acquired from a cache and is not coming directly from the filesystem hardware (which of course may or may not be disk-shaped). But you don't care, and no one thinks any less of you that you chose your words imprecisely. And if LabVIEW inserted some other gee-whiz functionality to further change the implementation of disk-reads over what the OS provides (the way they do with threading), then it still wouldn't be a reason to change the name.

Edited June 15, 2010 by jdunham

[jgcode]

Thoughts? Ideas?

From your research is a while loop running in parallel to other while loops (e.g. Main VI) always a thread?

[jdunham]

From your research is a while loop running in parallel to other while loops (e.g. Main VI) always a thread?

Well if you call them "LabVIEW threads", then 'yes', but if you mean OS threads, then 'possibly'.

My understanding is that the LV execution engine can use one or more OS threads, as it sees fit, to execute your compiled chunks of diagram code.

There is a little bit of explanation in the Labview Help under "LabVIEW Threading Model" (help index: "threading model") and "Execution Systems in LabVIEW" (help index: "multithreading, execution systems")

The explanations are rather brief, but basically you are not supposed to worry about it. Still it's helpful to know that LabVIEW threads are not OS threads, and neither are LabVIEW Execution Systems, just in case you are using some system analyzer tool which monitors OS threads and you see something different than you expect.

[Daklu]

From your research is a while loop running in parallel to other while loops (e.g. Main VI) always a thread?

To add to jdunham's response, in general there isn't a one-to-one mapping of os threads to data flow branches. (I'll use that term for now to avoid ambiguity. Still don't really like it.) The loop may execute on one os thread one time around and on another os thread the next time around. However, I think you can force parallel sub vis to execute in different os threads if you assign them to different LV execution systems.

To complicate matters, the compiler creates clumps of sequential instructions, but a clump may include multiple data flow branches. In the bd above SubVI1, SubVI2, and the Add prim may all be compiled into a single clump, so even though SubVI1 and SubVI2 theoretically execute in parallel, they are in fact sequenced and will execute on the same thread. Why not make the clumps smaller so SubVI1 and SubVI2 can really execute in parallel? If the clumps are too small, the program's execution time is dominated by managing the clumps and efficiency goes down. If the clumps are too big you lose parallelism and efficiency goes down. I haven't seen anything that describes how LV makes clumping decisions, so we have to accept that NI's compiler engineers know their stuff.

The explanations are rather brief, but basically you are not supposed to worry about it.

My take away from what I have read is that usually you don't need to worry about it, but sometimes you do.

----------------------

Here are a couple links I found:

Advances in Data Flow Programming Languages - A very good article on the history of data flow languages.

Ideas in Wiring: How Does Data Flow Execution Work? - A blog article from an NI engineer.

[Grampa_of_Oliva_n_Eden]

...

Thoughts? Ideas?

I was just reading the LV Performance Course book yesterday and I recall it.

Clump 1

Reads the two controls.

Clump2

Sub-VI 1

Clump 3

Sub-VI 2

Clump 4

Sub-VI 3 and 4

Clump 5

I would have to guess so I will not.

There is also a possibility that the Add subtract and GUI updates happen in Clump 1

Ben

[Daklu]

I was just reading the LV Performance Course book yesterday and I recall it.

I assume the sub vis may also be broken up into many clumps depending on their complexity?