LabVIEW Idea Exchange
I suggest to change the VI execution priority scheme from the current normal/above normal/high etc. to a scheme similar to timed structures with a priority number and CPU affinity:
Note that Enable automatic error handling and Auto handle menus at launch are off by default as they should be 
. I'd also expect enabling Inline subVI into calling VIs to disable and gray the rest of that form, since everything should be enherited from the caller VI anyway.
The reasons for my suggestion regarding VI priorities are multiple:
1) It seems background priority (lowest) has somewhat dubious effects (http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Remove-Background-priority-from-VI-Properties-Executio...).
2) Time critical priority is more than a priority, as it also doesn't yield the thread when it first gets hold of it. This detail can get lost when you're inexperienced in setting VI priorities, and I frequently see very unfortunate use of this setting (the most common being more VIs set to this than there are logical CPUs).
3) Subroutine priority is mostly, if not fully, replaced by the new code inlining functionality from LV 2010.
4) It is not recommended to mix timed structure priorities with VI priorities other than normal. I see this mixing frequently, making it quite hard to determine the true priority of the code.
5) It is often asked "at what priority runs my while loop?", "...my local?", "...my two parallel case structures?" etc. This would be simpler to understand if the entire VI had a priority that could be referenced absolutely to all other code using the same numbering system.
6) Timed structures run above high but below time critical priorities today. So we have a set of named priorities with a number range in-between. It would be much simpler if the numeric range covered all priorities, including the illusionary stuff that runs above time critical (NI Scan Engine for instance).
7) It would be quite simple to answer the question of at which priority runs 'TCP Read', or the SVE etc. There could even be a ceiling above which NI specific code could only run (maybe even a floor also).
😎 Regarding the processor assignment part; Today everything is multi-core, and we are in need of a simple way to set CPU affinity. This setting ought to exist globally for VIs.
If some code inside a VI need to run at a different priority than the VI setting, you can still just enclose that in a timed structure and set a localized priority. Priority enheritance to avoid priority inversion will still be in effect of course. It would just be much simpler to set and to understand how code chunks were prioritized in relation to each other. These settings should be readable and writeable through VI properties by the way, just like the input nodes on a timed structure allows for setting the priority at runtime.
A related, but not included in this idea, thought, is that it might also be time to get rid of the current execution system division scheme. It's not always obvious how many threads are available for each execution system. On Desktop there is (by default, this can be changed) 1 thread per logical CPU for each execution system. This is different on LV Real-Time, where there can be as many as 4 threads for some execution systems, but not all. Then there is 1 thread per LV instance for user interface, and 1 thread per timed structure (up to around 120 I think, I don't recall where I stumbled upon this upper limit, or if it's something I just dreamt up). It would be simpler if we had a single (user configurable maybe) threadpool, within that the simple priority numbering system I suggest above, as well as an ability to create a new thread programmatically (we can already do that by putting that code inside a timed loop or sequence, so no need for change here). Then there is the user interface thread. I'm not sure how to change that, if at all. It's actually a quite robust system, and we'd still be limited by stuff requiring root loop. That's how life is, and not going to change.
A new structure, a special case of the "single-frame timed sequence" for setting priority and CPU affinity should probably be created: The Priority structure. It has got nothing to do with timing anyway, the timed structures are just currently the only interfaces to setting priority and CPU affinity.
What do you think?
Cheers,
Steen
