Hi RDog,
I can't answer the behind the scenes details, but like you, I assume it is just wrapped APIs. There is a MultithreadingOverview.pdf available in the CVI help system if you search for 'multithreading'. However, I'll attempt explain the threading quickly--and others are certainly allowed to correct me.
-All of our CVI apps start with a single thread from the default thread pool
-There can be up to ATTR_TP_MAX_NUM_THREADS threads in this pool, which is 2 + 2*processor count
-All threads in the default pool always request normal priority
-If you want to do additional work without mucking up the GUI, you can create more threads from the default pool; if they ever finish they return to the pool, but a ghost of them remains in the idle state; you can see this if you use the debugger on a truly multithreaded app
-If you want to do additional work at a higher or lower priority than the default pool will allow, you need to create another pool; threads from the second pool can use the pool priority, or they can have their own individual priority above or below this
When RunUserInterface is active, your app is sitting 'idle'. As you use the interface, the mouse, the keyboard, or as other programmed callbacks come in, the main thread will leave RunUserInterface, do the required callbacks, and then return to RunUserInterface again. So, in response to your question about RunUserInterface()'s priority, it depends on what you are doing with other thread priorities. As you see from above, it can be higher or lower depending on how you write your program.
Notice above that I mentioned threads in the default pool 'request normal priority'. Regardless of what priority you specify for any thread, the O/S's scheduler (i.e. NT Scheduler--see MSDN library on web) actually decides when your thread gets to run. It is essentially using your specified priority as its goal. You can read a lot about the NT Scheduler all over the web, and I would encourage you to do so just to familiarize yourself with it. Typically, the scheduler does a good job about juggling priorities, and if your system has multiple processors it can do some even more impressive things.
I would also add a note of caution. You can really make a nice system run like poo if you design all of your apps to run at the highest priorities. I would suggest that you reserve higher priorities for threads that can run in short bursts and return to the pool quickly. You can set an app up to run just perfect on your system, but as you distribute it to other computers with hyperthreading and without hyperthreading your app can take on a whole new personality. Usually, this is not what you were intending to do. So experiment, and if things go downhill just go back to normal priority.
Orlan
