> --- 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 to 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.<p> > <i>And threads add overhead, especially when not used > appropriately.</i> 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. Perhaps this could be moved to reserve time, but priority inversion is a pretty big problem and deserves a pretty bulletproof solution. Greg McKaskle
