Questions on Multithreading with LabVIEW 8

[Ryan Duguay]

OS:                 Windows XP SP 2
Environment:  LabVIEW 8.2
Processor:     2 x Dual-Core Xeon 5160
Hardware:      DAQ (PXI-6254)
                       Frame Grabbber (PCI-1430)
                       GPIB (PXI-GPIB)

Greetings,

I'm building an application that will communicate with and control a handful of NI boards (listed above).  I want to be sure that I'm taking advantage of all 4 processors.  I've done a lot of reading (examples, tutorials, boards) and my own experimenting, but still haven't been able to gain a clear understanding of multithreaded development with LabVIEW.  I have many questions, but I hope that understanding these will answer the rest.  In fact a single explanation will likely answer both:

1)  My understanding is that there are 6 execution systems available to a VI.  By default LabVIEW allocates 4 threads to each execution system.  A VI can operate in any one of these systems, leading me to believe that any single VI can have (in the default configuration) at most 4 threads, and possibly one more for the UI (front panel) thread which is allocated by default for every VI (though this is unclear to me?).  In experimenting, I've built a simple VI, consisting merely of a stop button inside a while loop.  When I run the built application (standalone), the Windows Task Manager counts 13 threads for the entire process.  I then replicated my while loop 15 times, so that the VI has 16 independant while loops/stop button tasks.  Rebuild and the application still shows 13 threads in the WTM after building and executing.  I've tried using threadconfig.vi to change the configuration to "threads off", close/reopen LabVIEW, rebuild and the application still shows 13 threads.  If I set the execution system to Data Acquisition, Instrument I/O, or other (1 or 2), WTM shows 17 threads, regardless of the thread configuration set with threadconfig.vi or the number of loops in the VI.  Can someone explain what is going on?

2)  All of the literature seems to boil down to "Create well defined independant task on your block diagram, and LabVIEW will handle the rest."  Separating data flow between independant tasks on the block diagram is easy enough, but how do I go about confirming that my tasks are operating on separate threads and in parallel?

Thanks

[mfitzsimons]

Have you considered upgrading to LV 8.5?  You can select the core each thread runs on.  Otherwise in LV 8.2.x you just make independent loops and hope LV uses all cores available.

[Ryan Duguay]

Thanks for the suggestion Matthew.  Do you buy any chance work for NI?

Can you clear up any of my questions as they pertain to 8.2?  Why does a simple while loop spawn 13 threads?  With a better understanding, I should be able to make a better judgement as to the best solution.  Maybe the answer is 8.5, but I'd need a little more information to feel comfortable with it.

Thanks again.

[mfitzsimons]

Ryan,

No I don't work for NI but it sounds like the latest version has what you are looking for.  I actually didn't know that it spawned 13 threads and do not have that deep of an insight to the inner workings of LabVIEW.  Looking forward to the other responses.  I find it almost as interesting that the discussion forum spell checker doesn't know how to spell LabVIEW.

[Ryan Duguay]

I'm still having trouble building a clear understanding of multithreading in LabVIEW.  The support documents I've found on the subject really don't go into much detail and don't explain what I'm seeing.  Can anyone offer some insight or point me to where I can find for detailed information in thread control?

Thanks

[Ben]

THe best write-up is under "hyper-threading". The number of threads can be configured.

See here and here for previous discussions.

After reviewing those threads please post back if you have follow-up Q's.

Ben

[Ryan Duguay]

Thanks Ben,

Unfortunately these really don't answer my questions.  I have a 4 core system.  If I set the execution system of even a simple, single loop VI to Data Acquisition, Instrument I/O, or other (1 or 2), Windows Task Manager shows 17 threads for the built (standalone) executable.  All other execution systems create 13 threads.  Changing the number of threads for each execution system via the threadconfig utility seems to have no effect on the executable; that is, WTM always shows 17 or 13 threads.  I'm trying to understand this behavior.

I've done some more experimenting and I've at least been able to see that with four independent loops running, I can utilize all 4 cores.  I guess this answers my original question 2), and makes me feel a bit better.  If I would like one of the threads to have higher priority, is it as simple as placing that code into a subVI and setting it's priority higher?  Will it then run at a higher priority than the main VI that it was called from?

Thanks again.

[Anthony_de_Vries]

I think the first question should be wether there actually is a problem...     If you have 4 loops running at full speed, do all cores show 100%?   What happens if you close down one of the cores?      If Labview runs the cores at max efficiency allready, maybe you simply should be happy that you don't need to care about it...

I quickly tried om my developement machine.  (LV 8.5 on a dual-core)    With multiple loops, I have both cores at 100%. Stopping those loops one after the other, the CPU's stay at 100% right untill the point where I have only one loop left.  Then one core is idle, and the other is still at max.  Only once, I saw the situation where both cores where at 50% for about half a second... and then one core went to 100%, and the other to idle. 

From that last observation, I would guess that Labview has it's own thread scheduler, and problably has one thread for every available core, or something like that.

[Ryan Duguay]

That's exactly what I found.  When running four loops, I can utilize 4 cores, at around 75% each.  As I stop each loop in succession, I can see the processor loads drop off, first core 4, then core 2.   When I'm down to a single running loop, all 4 cores become active again, with varying loads averaging out to about 25% of the total system.   So I agree that LabVIEW seems to be handling things just fine and I've got nothing to worry about. 

Still curious about the large number of threads that are spawned even for a simple single loop.  I'm beginning to guess that LabVIEW creates a predetermined number of threads regardless of the application specifics.  The "work" is then assigned to the different threads as appropriate and necessary.  Hopefully the spare threads sit quietly.  Maybe this was supposed to be clear in the documentation and articles, but it wasn't clear to me.  For now I'm moving on, but it would be aesthetically pleasing to be able to limit the number of threads to the minimum necessary.

Thanks everyone for your help.