Threads

[rtyson]

I am playing with using threads in Labwindows.  My application does nor require a user interface, that will be a separate application.

So, do I need to call RunUserInterface() if I launch my threads myself and 'spin' in main - the main thread ?

Since I don't require a UserInterface at my application level does calling RunUserInterface() have any disadvantages as oppose to advantages ?  I have always had a user interface for my applications.

If I did call RunUserInterface() and provided a timer Callback would this pre-empt a thread execution ?

Is there a method for setting a threads priority using labwindows thread lib ?

What are the equivalent mutexes(1 resource)/semaphores(# of resources) for labwindows threads ? 

I read about the Create/Get/ReleaseLock in Labwindows but is this the only 'synchronizing' available in the Labwindows thread lib ???????

RTyson 

[cosmo]

Hi RTyson,

  As far as I know, you don't need RunUserInterface() unless you actually display a user interface.  In a situation similar to yours, I call ProcessSystemEvents() in a loop.  Depending on the functions that your program will call, there will be times when hidden windows will be created.  ProcessSystemEvents() gives your program a chance to clear the list of queued events, including windows messages (WM_'s).  You may need to do this in each of the threads--again depending on what you want to do.

  You may have already seen this: https://www.ni.com/en/support/documentation/supplemental/06/multithreading-in-labwindows--cvi.html  There is also: MultithreadingOverview.pdf in your \bin directory where CVI is installed.

  Priorities for threads are adjustable via CmtScheduleThreadPoolFunctionAdv(), or they can assume the default priority of the thread pool from which they were spawned from.  There may be other methods for doing these directly with the API, but CVI provides these functions natively and they work well.  Be mindful of changing thread priorities too much.  If the target computer is vastly different from the development computer (in hardware, active programs, with unpredictable user interaction, programs added by the user after deployment, etc.) you program could either run like poo, or drag the computer to its knees.  Some testing will be required.

Good luck,

Orlan

[bilalD]

Some other cases where you might need processsystemevents in the other thread would be if you are using CVI Serial library callbacks and tcp callbacks. In these cases, you need to make sure the events are processed for the appropriate callbacks to be fired.

[menchar]

I've always preferred to use the native Win32 API calls for creating / manipulating threads - seems simpler to me than learning how NI has repackaged these, since CVI threads ultimately are native OS threads.   Personally, I find the NI thread functions more confusing than learning about and using the native Win32 API calls, but I knew these before I started doing multithreading with CVI.

I wouldn't "spin" anywhere - I'd use Sleep() or SleepEx() and "wake up" periodically and process system events.  The N.I. Delay() function doesn't periodically check for events that have been posted but not processed.

If you're just trying to coordinated threads within a single process, the easiest and "lightest weight" mechanism to use is a critical section rather than a kernel object.  You might want to see "Multithreading Applications in Win32", Beveridge & Weiner, ISBN 0-201-44234-5, somewhat dated but still best reference around maybe.