LabVIEW Idea Exchange

If I get the sematic of trace memory allocations right, every "Memory Allocate" event for a given handle should be accompanied by a "Memory Free" event somewhen later for the same handle or there is a memory leak. Given that, the trace toolkit desperately needs a feature that highlights all "Memory Allocate" events where no free event exists. Moreover, the event details should not only contain the VI that allocated the memory but also the concrete diagram element. Optimal would be switching to Labview and highlighting the element in the diagram just like the "LabVIEW Compare" tool does.

For now I'm helping myself by

• exporting the traces to text,
• deleting everything except the handle in "Details" using regular expressions in ultra edit: ;^(?*^)^p
• deleting all "Memory Resize" events for performance reasons: ^p^(?*^)Memory Resize^(?*^)^p
• renaming the column name "#" with "ID"
• importing the text file into an access database
• executing an SQL statement that gives me the ID's of all open memory allocations:

SELECT jo.id
FROM (
  SELECT q1.id, c.Beginn 
  FROM queueTest2 AS q1 LEFT JOIN (
       SELECT q1.vi, q1.id AS Beginn, Min(q2.id) AS Ende
       FROM queueTest2 AS q1, queueTest2 AS q2
       WHERE q1.event='Memory Allocate' 
       And q2.event='Memory Free' 
       And q1.id<q2.id 
       And q1.Details=q2.Details
       GROUP BY q1.id, q1.vi) AS c 
  ON (q1.id=c.Beginn AND q1.Event='Memory Allocate'))  AS jo
WHERE isNull(jo.Beginn)

Please note that a Bug in MS Access 2007 reformats this statement on saving it in a way that executing it gives an join expression not supported error. This can be fixed by putting the ON statement into braces again (don't press save before executing).

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-Execution-since-it/idi-p/1637938).

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