Jeff, Altenbach, thanks for the link about floating point calculation. I should have paid more attention to Jeff's emphasis on meaningful.
Jyang72211: Your analogy doesn't quite work.
Only one processor works on a single thread at a time - that is, a thread gets assigned to a processor when that thread is running. The operating system can halt a thread and swap it to another processor, but the thread is never on two processors simultaneously.
A normal (non-subroutine VI) gets broken up into "clumps" during compilation. When it runs, the scheduler grabs a clump and hands it off to the next available thread in that execution system. Since an execution system has multiple threads, different parts of the VI could execute in different threads, possibly on different processors, and could even execute in parallel.
A subroutine VI executes as a single clump. This also means that a subroutine won't really execute parallel tasks in parallel - they'll execute in a single thread on a single processor. It might look like two parts execute in parallel if instructions for parallel tasks gets interleaved during compilation, but they won't actually execute concurrently the way they could in a non-subroutine. This is why you can't put a parallelized For Loop in a subroutine. Another example of a single thread in LabVIEW is a timed loop, "any code enclosed within the timed loop executes in a single thread." (Don't ask me why parallelized for loops are allowed in timed loops; I assume they just don't execute in parallel but haven't benchmarked it.)
See the help for execution subsystems. Each execution subsystem (except the User Interface) is a separate pool of threads. By assigning VIs to separate execution subsystems, you can prevent one group of VIs from monopolizing all available threads. For example, say you have a bunch of loops that all communicate with slow external devices. Each communication might be a separate thread, which could block while waiting for the device to respond. If all your code is in the same execution subsystem, this could prevent anything else from running. By limiting those communications to a separate execution subsystem, you partition that communication so it doesn't interfere with the rest of your code. That said, most of the time you don't have this situation, and as noted in one of the links in this thread you should leave VIs set to "Same as caller" unless you know that they should execute elsewhere. Often you'll assign separate execution subsystems to only a few long-running, almost top-level VIs.
