call by reference timeout?

[dthomson]

I've got a system in which there are numerous top-level VI's running in parallel. One of them will obtain a reference to a functional global and then share that reference with other top-level VIs. Each of these VI's can then call the functional global and have it execute various commands on its data. Most of these calls are brief, but one (load a file) can take several seconds, depending on the file size. Normally, everything works fine, but if the functional global is reading a long file and another VI tries to access it, the 2nd call gets an error 1026, reference not valid.

A Call by Reference is similar to a sub-vi call. I would expect that the LV scheduling system would queue up requests to the functional global like it would for any other sub-vi call. I think this works in general, when calls are of short duration. I've never noticed other 1026 errors, whereas there should have been some coincidental calls by now in al the times that the program has been running. But, if I ask the functional global to read a really large file, which takes seconds, then a simultaneous call from another VI gives 1026. I've verified this by adding a simple delay of several seconds, letting the file read finish before making the same call from the 2nd VI. That works fine, so it really seems that 1026 is returned when the VI is busy, but only when it is busy for a longgg time.

I haven't been able to find documentation on this feature. It makes a certain amount of sense, but surprises me since it apparently isn't documented. Does anyone else know about this "feature"?

Thanks,

DaveT

[Yair]

I think the problem might come from the file I/O, not the wait itself. If you do a test where the VI just waits, you should see that it behaves as expected.

I seem to remember that some I/O operations halt the LabVIEW root loop and this might be what's causing this. If it is, I would assume that it is a bug or at least should be officially brought to NI with an example.

[LAVA 1.0 Content]

QUOTE(dthomson @ Feb 16 2008, 12:50 PM)

I've got a system in which there are numerous top-level VI's running in parallel. One of them will obtain a reference to a functional global and then share that reference with other top-level VIs. Each of these VI's can then call the functional global and have it execute various commands on its data. Most of these calls are brief, but one (load a file) can take several seconds, depending on the file size. Normally, everything works fine, but if the functional global is reading a long file and another VI tries to access it, the 2nd call gets an error 1026, reference not valid.

A Call by Reference is similar to a sub-vi call. I would expect that the LV scheduling system would queue up requests to the functional global like it would for any other sub-vi call. I think this works in general, when calls are of short duration. I've never noticed other 1026 errors, whereas there should have been some coincidental calls by now in al the times that the program has been running. But, if I ask the functional global to read a really large file, which takes seconds, then a simultaneous call from another VI gives 1026. I've verified this by adding a simple delay of several seconds, letting the file read finish before making the same call from the 2nd VI. That works fine, so it really seems that 1026 is returned when the VI is busy, but only when it is busy for a longgg time.

I haven't been able to find documentation on this feature. It makes a certain amount of sense, but surprises me since it apparently isn't documented. Does anyone else know about this "feature"?

Thanks,

DaveT

Also why dont you lock your functional global with a semaphore to avoid unnecessar access from other toplevel vi's?

[Aristos Queue]

QUOTE(guruthilak@yahoo.com @ Feb 19 2008, 12:54 AM)

Also why dont you lock your functional global with a semaphore to avoid unnecessar access from other toplevel vi's?

The whole point of a functional global is you don't need a semaphore. Only one VI can call any given subVI at a time -- if you want more than one to be able to call simultaneously, make the VI reentrant, which is, in effect, creating separate VIs for every caller. But for a non-reentrant subVI, only one caller can call at a time, so you don't need semaphores.

To dthomson: Sorry, I don't have anything to say to help with your issue. I've never seen a problem with this and I'd have to see some code to make any guesses about what is wrong.

[dthomson]

QUOTE(guruthilak@yahoo.com @ Feb 18 2008, 11:54 PM)

Also why dont you lock your functional global with a semaphore to avoid unnecessar access from other toplevel vi's?

Guru, Interesting idea. However, I assumed that was what LabVIEW was doing for me. I've built whole systems on the basis of this (for sub-vi's, not for dynamicly-called VI). I use a single VI to access a resource/driver/object, and can call that VI from multiple top-level LV VI's confident that LabVIEW's scheduler will prevent simultaneous calls to the non-reentrant VI. So I guess the question is, is there any reason (other than the error I've seen) to believe that dynamically called VIs should be any different?Yen, Thanks for the idea. I wrote some test code to demonstrate this. One vi that spins its wheels with arithmetic for n seconds, with an optional second loop that reads a really big file. Two callers that each call that VI dynamically. Regardless of whether the file reading option is on, both callers operate as expected, with one minor exception: Without file reading, the second VI obviously waits for the first to finish before it starts. E.g. if they are both set to 3 seconds and both started at almost the same time, the 1st finishes in 3 seconds and the 2nd in 6 seconds. However, with file reading on, both VI's run without error and read the correct data, but their run arrows both turn blank at the same time! They don't "appear" to be sequential. So although I'm not getting the same error, maybe it is doing the same thing at some level...DaveTQUOTE(Aristos Queue @ Feb 19 2008, 12:13 PM)

The whole point of a functional global is you don't need a semaphore. Only one VI can call any given subVI at a time -- if you want more than one to be able to call simultaneously, make the VI reentrant, which is, in effect, creating separate VIs for every caller. But for a non-reentrant subVI, only one caller can call at a time, so you don't need semaphores.

To dthomson:

Sorry, I don't have anything to say to help with your issue. I've never seen a problem with this and I'd have to see some code to make any guesses about what is wrong.

Aristos, Didn't see your post until just after I replied. Given my observations with the test program, do you think that is enough to submit to NI for further investigation? Actually, I just ran it again a few times. There are subtle hints that they are running sequentially, and that it is only a front-panel update issue that turns the run arrows off at the same time. The window titles get updated about half-way through, suggesting that they run sequentially, but the windows don't get fully graphically updated until both are done since the cpu is maxed out. So I'm beginning to conclude that my demo is a bust. It should have the same basic features as the full program, but I haven't been able to duplicate the problem yet...Dave

[TG]

QUOTE(dthomson @ Feb 16 2008, 05:50 PM)

I've got a system in which there are numerous top-level VI's running in parallel. One of them will obtain a reference to a functional global and then share that reference with other top-level VIs. Each of these VI's can then call the functional global and have it execute various commands .....

if the functional global is reading a long file and another VI tries to access it, the 2nd call gets an error 1026, reference not valid.

A Call by Reference is similar to a sub-vi call. I would expect that the LV scheduling system would queue up requests to the functional global like it would for any other sub-vi call.

I haven't been able to find documentation on this feature. It makes a certain amount of sense, but surprises me since it apparently isn't documented. Does anyone else know about this "feature"?

Thanks,

DaveT

Sounds to me like the scheduler is not handling the refwerence correctly or the error is normal under your scenario.

The ref goes invalid because it is in use by the long running VI perhaps?

The other Vi sees a locked or busy reference and then assumes it is invalid after a timeout?

I can feel ears perking up right now LOL!

I may have run into stuff similar to this before but usually I go bezerk and just fall back on a crappy work around to keep things moving along.

Like repeatedly testing the reference in a loop (ignoring 1026 error) until it becomes valid again (with a timeout of course).

Just thinking out loud here...

one thing I know is LV sometimes invalidates references with me but the rules are not so clear as to why. Its always a valid reason but still

somewhat of a pain to track down.

As an addendum to my senseless gabbing I think if you have not already digested this it might be helpful. At least there may be a clue there and an idea as to how to proceed.

http://wiki.lavag.org/Lessons_learned_from_plugins

[Aristos Queue]

This is the sort of issue that would be better posted to the ni.com DevForums. The NI application engineers there will be able to dig deeper into it and figure out if you've got a bug or not.