Why does priority of NON RUNNING vi affects execution time of subVI?

[Ben]

That should have read,

100% sir/madam

Ben

[Greg_McKaskle2]

> Regardless, I am working fine with subroutine priority, but I want to
> understand things better. I've read the app note (#114, I think), but
> I can't see a connection between the words there and my situation
> here.

I asked around at work and it is definitely priority inversion. Here is
how it affects things. When you have a shared nonreentrant subVI, and
one caller is high priority and one is lower, then the subVI's priority
is boosted to match the higher of the callers.

This boosting means that the higher priority caller matches, but the
lower priority VI will need to go through thread context switches to and
from the high priority subVI calls. If the subVI doesn't do much work,
then the overhead
can swamp out the work performed by the subVI.

This begs the question as to why the call priorities are really
different. I have tried to hint at the before, but I'll say it
explicitly. Priorities do not pipe higher octane electrons through your
computer. Priorities can only speed one thing up by slowing another
down. And threads add overhead, especially when not used appropriately.

Greg McKaskle

[CoastalMaineBird]

When you have a shared nonreentrant subVI, and
one caller is high priority and one is lower, then the subVI's priority
is boosted to match the higher of the callers.

--- You suggested this before and all tests seem to bear this out.

but the
lower priority VI will need to go through thread context switches to and
from the high priority subVI calls.
--- This was our inferred explanation - good to have confirmation. I'm still not sure why a priority-switch is equated to a thread switch, though.

Priorities do not pipe higher octane electrons through your computer.  Priorities can only speed one thing up by slowing another down.
--- I understand that. What was a mystery
(and is now explained) is that the subVI is treated as a shared resource EVEN THOUGH there is no competition for it (only one caller). On the face of it, it doesn't make sense for priorities to be involved at all when a single call to a single VI is used. But, you have to go through the same motions, because you don't really know if another VI might call it or not.
Also, what was a mystery was the fact that if A calls B, then B's priority is boosted, if necessary, to match A's. And this occurs AT COMPILE TIME, whether the A--> B call is actually executed or not.

And threads add overhead, especially when not used appropriately.
--- Threads only entered into this as experiments to explain what is happening. I started with everything on the default (SAME AS CALLER) thread.

[CoastalMaineBird]

When you have a shared nonreentrant subVI, and
one caller is high priority and one is lower, then the subVI's priority
is boosted to match the higher of the callers.

--- Notice that my later tests prove that you don't need TWO callers. The same effect is apparent with only ONE caller.

To recap: here are the mysteries solved:

1... If A calls B, and B's priority is higher, a context switch overhead is incurred.
2... If A calls B, and C calls B, then B's priority is boosted, if necessary, to match the higher of A's or C's priority.
3... # 2 applies EVEN if one of the callers is not even running.

It's the combination of these three that confused me.

Thanks, Greg and Ben!

[Greg_McKaskle2]

> --- This was our inferred explanation - good to have confirmation. I'm
> still not sure why a priority-switch is equated to a thread switch,
> though.

It isn't obvious, is it. OSes add multitasking and priority execution
by adding the abstract process and thread concepts. Threads and
processes are the SW abstraction of the processing engine or CPU,
essentially giving each bit of code its own virtual CPU to run on.
Threads and processes are where you assign priorities, and while it may
be possible to boost priorities back and forth for a single thread or
process, that isn't necessarily very fast either. So in weighing
different implementations, it was decided to have multiple threads t
o
schedule code on rather than have VI threads that switch priorities.


> --- I understand that. What was a mystery (and is now explained) is
> that the subVI is treated as a shared resource EVEN THOUGH there is no
> competition for it (only one caller). On the face of it, it doesn't
> make sense for priorities to be involved at all when a single call to
> a single VI is used. But, you have to go through the same motions,
> because you don't really know if another VI might call it or not.
> Also, what was a mystery was the fact that if A calls B, then B's
> priority is boosted, if necessary, to match A's. And this occurs AT
> COMPILE TIME, whether the A--> B call is actually executed or not.

> And threads add overhead, especially when not used
> appropriately.

This is done so that if you run A, then run B, C is already ready to go.
By the way, this doesn't happen at compile time as the VI doesn't need
to be recompiled for this to happen, but it does happen on load.
P
erhaps this could be moved to reserve time, but priority inversion is a
pretty big problem and deserves a pretty bulletproof solution.

Greg McKaskle

[CoastalMaineBird]

OK, that's farther up the CompSci tree than -I- can follow, but as long as it's a known behavior, I can deal with it.

  By the way, this doesn't happen at compile time as the VI doesn't need to be recompiled for this to happen, but it does happen on load.

That makes sense, because in my real object the dummy caller is BROKEN and won't compile (required connections are missing), but the behavior happens anyway.


I wonder what happens if the high-priority caller is loaded WHILE the low-priority system is running. Do priorities change DURING execution?
No answer necessary- If I really want to know, I'll test it and find out.

[Ben]

You are welcome!

There was a pay-off for me in this game. We will probably be using this example in the LV Intermediate course we teach if the instructors are asked to demonstrate this behaviour.

Ben