SubVI with "Subroutine"-priority

Question

It's known that it is impossible to call a non-"Subroutine"-SubVI from a
SubVI with "Subroutine"-priority. Actually subroutines are much faster,
because they do not create their own thread, as SubVIs with other
priority-levels do.
Is it possibly to force Labview not executing an own thread for every SubVI
that has a higher priority than "Subroutine" ?!?
Philipp

Answer 1

> It's known that it is impossible to call a non-"Subroutine"-SubVI from a
> SubVI with "Subroutine"-priority. Actually subroutines are much faster,
> because they do not create their own thread, as SubVIs with other
> priority-levels do.
> Is it possibly to force Labview not executing an own thread for every SubVI
> that has a higher priority than "Subroutine" ?!?
>
Actually things are a bit different than what you describe. SubVIs are set
to run in an execution system. All execution systems that are being used
will have threads created for them before the VI even begins to run. It
is the execution systems that define how many threads, not the VIs. Any and
all VIs that use an execution system share the threads. By default, each
execution system has one thread per priority per processor.
If each subVI uses a different execution system, and provided threading is
enabled, each subVI will be run by a different thread. This does cause
overhead due to the thread switches that the operating system must perform.
For that reason, it is usually best to leave the VIs in their default
setting -- running in the same thread as the caller. This avoids the thread
switch, and it allows for lots of freedom in later configurations. Here is
how. If you now have several tasks that you want to separate, you make them
subVIs and set them to different execution systems/priorities. Then any
subVI they call will inherit the execution system, the priority, and the
thread automatically without lots of reconfiguring or duplication of VIs.
Lastly, the subroutine is sort of an odd feature. It really isn't a
priority at all. A subroutine is a special way of compiling a VI that
turns off everything possible to make the VI run as efficiently as
currently possible. They always run in the thread of the caller, they
do not co-routine with other VIs of the same priority.
Subroutines turn off
debugging -- you cannot probe, set a breakpoint, or use highlighting
panel interaction -- the panel is not read or written to while the VI
runs ...
scheduling -- the VI cannot call VIs that aren't also subroutines, it cannot
have any asynchronous functions, sleeps, etc.
So, the best way to think of a subroutine is as a function call with as
little overhead as possible. Not all code can be turned into a subroutine,
and you should wait until the code is debugged before making subroutines.
It is also a good idea to use the profiler to point out the most commonly
called subVIs. If a subVI is only called two times, it is hardly worth
the effort of making it a subroutine. If a subVI is called 2,000,000 times,
then trimming off even a small amount per call can do wonders to speed up
your app.
Greg McKaskle