LabVIEW 7.0 multithreaded executable broken?

[Kevin Valentine]

I'm having a slight problem with multithreading in LV70. I've written a small app that I use to verify the thread configuration in LV61 and LV70. It dynamically loads and runs n copies of a reentrant VI. In my example interations(n) = 100. When I compile them into executables, I notice some strange things happening in the LV70 version of the executable. Sometime one of the elements in the time array doesn't update. It's usually the 8th element but I've seen it happen on higher elements too. This never happens on the LV61 executable.

Another thing. Both LV environments have been threadconfig'ed for eight threads. When I look in the Windows Task Manager under Processes, I see that Reentrant61.exe and Reentrant70.exe are using
7 and 11 threads, respectively.

Attached is a zip file containing source VIs saved in version LV61 and LV70. Make sure to use .bld files provided when compiling your executable.

Stop and run each executable a few times and pay careful attention to the LV70 version. You'll see that some of the values never change. They stay at "08:00:00.000 PM". For example, out of one 100 iteration test I noticed that array elements 8, 19, 31, 43, 68, 79, and 88 never changed.

What's going on here?
-Kevin

[Kevin Valentine]

Woops!
Forgot the attachment. I always do that...

[Jeremy Braden]

This is weird. I saw the behavior you described and I got the 7.0 VI to not update in the development environment. You might want to contact technical support at www.ni.com/ask .

[Kevin Valentine]

I duplicated the problem on a WinXP system and I found a few more things. I thought about what you said about the dev env not updating so I modified the dynamic VI so that it will also write the time stamps to its own unique file and not just the display. This allowed me to determine if it's just a display update problem. You won't believe what I found (well, I was surprised). If you don't see it in the display, you won't find the file either. It's like instances of the VI call are just being dropped. What's even worse is that it doesn't have to be an executable. I was seeing this in the development environment!

I considered that perhaps it has something to do with the amount of iterations I was using so I kept scaling it back until
the behavior stopped. It never did. I got down to two iterations and it still did it!

This is a very bad thing to me. I've contacted NI support and an Application Engineer got back to me. He said it appears to be a bug and R&D will get to it. I think it's a good idea for the LabVIEW community to discuss this. Calling VIs dynamically is very common in my applications because it's useful as a bare-bones test executive. I can't do my work efficiently without this feature.

Attached is a zipped copy of my test. It doesn't have a .bld file or a LV61 version. Let me know of there's a problem with the zip file or the app.

-Kevin

PS: I'm open to the idea that my test is inaccurate. Someone please let me know if this is true.

[Kevin Valentine]

Hi again,
My bug tester had a slight bug in it when using high iterations. The rendezvous kept getting timeouts. This one should fix that.

-Kevin

[Antonio Costantino]

hi Kelvin,
Sorry for my English, I try your software and I think that the problem is the medoth with wich you call the reentrant VI.
The software updates the global variable INDEX and starts the reentrant VI. Maybe there is a race condition that permits to start two o more VI with the
same index (check the log file).
Try to insert a sequence to:
1 - update the global variable INDEX
2 - start the reentrant VI
3 - wait for few milliseconds.
it seems to works.