Different behavior for a VI from lvlibp.

[wladimiripg]

I have an VI that displays data on a string indicator. That vi run with a low priority. 

1. I use that VI as a SubVI parallel to 32 while loops without wait. The string indicator will display new values.

2. When I use the lvlibp version of the vi. The string indicator will not be updated. Until I stop one while loop.

Tested on LabVIEW Professional 15.0.1f7, W7 Professional, 2x Intel Xeon E5-2640. (32 logic processors)

3. On a PC with Xeon E3-1245 ( 8 logic cores) I have to stop at least 8 loops until the Indicator starts to display actual values.

4. lvlibp version with normal priority has the same behaviour like the subvi. ( Or I need more loops to see the difference).

Can somebody tell me why i see a different behaviour between 1 and 2?

[CoastalMaineBird]

It's hard to figure what you're trying to do here, except heat up your CPU:

You've got 32 loops, each trying to read it's own STOP button, as fast as it can.  That's going to starve your CPU.  Are you intentionally trying to stress the CPU, or trying to do something else?

[CoastalMaineBird]

If I build the PPL ('StatusNormal.lvlibp') under LV 2017 (I had to , to get it to link), then I notice no behavior difference between using the PPL and using the VI directly.

I am using LV2017 under Windows 7 under VMWare on an old (2009) OS X machine - I don't know if that affects the issue or not. But it behaves the same as far as I can see.

[wladimiripg]

The 32 loops are here just to simulate some parallel process. My problem is the different behaviour of the WS_StatusStringAktualisieren.vi. If use it direct as a subvi, the string indicator will be updated. If use it as part of an lvlibp, then the string indicator will not be updated until i stop one of the 31 loops (stop 2-32). 

[CoastalMaineBird]

Since the Build Spec turns off the ALLOW DEBUGGING option, maybe there is some other debugging hooks that are removed when building the PPL, compared to the VI itself (even though it also has debugging OFF).   Try building the PPL with debugging ON, to see if it makes a difference.

Anyway, I see no difference here, but I'm not pushing the speed very fast.

[wladimiripg]

I compiled it with allow debugging, i see no difference.

[Norbert_B]

This is a classic case of bad resource management.

Hogging the cores of a CPU with tasks which must not be interrupted (except by higher priority tasks) always has system specific behavior.

It is possible that the OS or the CPU or maybe the motherboard you have creates that difference.

As Steve pointed out, there might be slight differences in the compiled code due to compiler settings (and what i add) or by compiler environment/situation. The LV compiler always creates a new compilation when create a package or have uncompiled changes and run the VI. These differences can lead to the fact, that different loops are assigned to cores differently by the OS. As you hog without a wait of 0, a hogging loop does NOT allow other loops to execute as long as these have the same priority.

Conclusion:

Add a wait of 0 in each loop and verify how the behavior changes.

[wladimiripg]

If i add some wait functions, then the behaviour is the same.

But it was just a small example. I can't upload the main project. In the main project i don't have 31 greedy loops and the cpu load is not more then 10%. But still don't see Indicator updates, when i use that vi from a lvlibp.

[Norbert_B]

If that is the case, there is something blocking the UI thread. Please make sure that the caller or parallel running stuff is not running in UI thread for extended time (e.g. Call Library Function Node).

[wladimiripg]

I use a subpanel, and the parallel stuff is Producer Consumer State machine with two while loops. One with an event structure and one with dequeue element. Can some of them block the UI thread?