<i>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.
</i>
--- You suggested this before and all tests seem to bear this out.<p>
<i>but the
lower priority VI will need to go through thread context switches to
and
from the high priority subVI calls.</i>
--- 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.<p>
<i>Priorities do not pipe higher octane electrons through your
computer.=A0 Priorities can only speed one thing up by slowing another
down.</i>
--- I understand that. What was a mystery (and is now explained) is
that the subVI is treated=A0as 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.<p>
<i>And threads add overhead, especially when not used
appropriately.</i>
--- Threads only entered into this as experiments to explain what is
happening. I started with everything on the default (SAME AS CALLER)
thread.
