Subroutine Priority

[jyang72211]

Select subroutine priority to make the LabVIEW execution system run the VI as efficiently as possible. VIs that you set for Subroutine priority do not share execution time with other VIs.  What does it mean by not sharing executing time with other VIs?  Doesn't it just mean running in parallel?  If that the case, what's so special about this priority?

[nathand]

I think if you continue reading the help on priorities past the part you quoted, it's clear. The thread in which the subroutine VI is executing runs only the subroutine. Other VIs can be running in parallel so long as they're executing in other threads. If the concept of threads isn't clear, you may want to do some reading. As a rough analogy you can think of threads as processors. When the subroutine is running, it is the only VI running on that particular processor, but other processors can be running other tasks. Non-subroutine VIs can share use of a thread, where one section of a VI runs, then a section of another VI, etc.

[mikeporter]

The documentation on the subroutine priority says that a VI so configured:

"...blocks the execution of other VIs on the same thread until it and all its subVIs finish executing."

That is what is so special. Losing parallelism on a thread is very "special".

Mike...

[crossrulz]

As a rule of thumb, I avoid using the subroutine priority.  You lose debugging capability, it blocks other parts of the thread.  I will concider setting to subroutine only for quick functions where I need the extra bit of power to get a lot of processing done.

[JÞB]

Good question and the fine details depend on the specifics of how your operating system assigns CPU time to processes.  In most normal cases the OS can interupt a process and give time to some other process that is waiting to use the CPU.  Subroutine priority forces the vi to operate "atomically" or, once it starts it must complete without any interuptions.  This is certanly effecient since interuption really mean: take my data off the CPU stack, store it in a place we can find it later, put the other data in the stack, process other instructions, swap data again, resume my process instructions see if another process deserves to interupt me again.  The fine points of negotiating CPU time vary quite a bit.  Subroutine simply lobotomizes the OS negotiations.  Care should be taken when setting this priority however since the CPU WILL be dedicated to the process and cannot be interupted (You can't even "Abort" a vi running subroutine priority!)  In most cases setting this property is absolutely the wrong thing to do and can cause problem with other processes waiting for the CPU time they need like unexpected timeouts throwing exceptions, errors, to their callers.  Imagine an infinate loop running subroutine......total lockup of the machine!

Thankfully LabVIEW protects us from ourselves in the most obvious cases where subroutine priority would be simply devistating by breaking the vi.  Situations like "We cannot tell how much processing will really be needed" such as while loops or event structures (Asynchronous nodes) cannot be used in a vi set to subroutine priority since the number of iterations for the while loop is unknown and the timing of the event is unknown. 

In short: Subroutine priority is there because the OS will allow it because in extreemely rare cases it is necessary to process a set of instructions atomically.  In the vast majority of cases though the result of the instruction set would not be meaningfully effected by interuption.  (e.g. floating point operations may be affected by interuption but only by an umpteenth significant digit which is usually not meaningful)

[nathand]

Jeff - that's not quite right. Subroutine priority tells the subVI to run atomically within the thread, but not necessarily within the processor. The operating system can still interrupt it, and for that matter other LabVIEW threads can continue running concurrently. I disagree that setting subroutine priority is "absolutely" the wrong thing to do - when performance matters, it is the right thing to do for most VIs that do only calculations. It just shouldn't be used for subVIs that run continuously.

Also, the floating-point case comment is probably irrelevant on modern processors since they off-load all that processing to a floating-point unit, but in any case the result of a computation should never be affected by a thread switch (meaningfully or otherwise).

[JÞB]

Thanks for cleaning up that misstatement confussing threads and processors.  To clarify the relationship.  One Thread per Processor Per Execution system is the out of the box LabVIEW configuration.  It can be changed but that is another box of worms entirely.

As for thread swap causing differing results well.....see here (as the likely cause of just such behavior observed by Altenbach elsewhere)

{EDIT} Did you think I was asleep at the wheel Christian?

[altenbach]

---

@nathand wrote:

Also, the floating-point case comment is probably irrelevant on modern processors since they off-load all that processing to a floating-point unit, but in any case the result of a computation should never be affected by a thread switch (meaningfully or otherwise).

---

FP results can even vary if no thread switch is involved. Elsewhere, I was pointed to this article. So be surprised. 😄

(EDIT: Interesting Jeff just posted the same link above !)

[TiTou]

Some more information here on LAVA that includes a link to a post on NI Forum from Greg McKaskle (aren't we just running in circles??)

[jyang72211]

Good explaination.  Let me make sure I understand.  I my summary current below?

Subroutine priority vi

1. will run from start to finish without any interruption (run atomically)

2. will run in one thread, but the vi maybe executed by different processors

In short, subroutine priority will allow a VI to run faster because the VI would run atomically.