Subroutines and Inline VIs

[mje]

Hi gang, it's been a while.

I'm trying to squeeze performance out of one of my consumer loops which is being outpaced by it's producer and came across this little ditty:

Full error text: Subroutine priority VI cannot call a non-subroutine priority subVI.

The rub here is all the SubVIs called are inline accessor methods, but LabVIEW won't have any of it since they're not explicitly given the subroutine priority. The errors clear if I assign the inline VIs to subroutine priority. Is this intended?

TL;DR: It would seem the inline code preserves its priority setting independent of the caller. Or it's a bug.

I get that inline code doesn't quite act the same as if you'd dropped the same code onto the calling diagram. There's an implicit context at play, as if you had slapped a single frame sequence structure around your code. If I have an inline VI that simply rotates an array for example and call it from another VI we effectively get:

The sequence frame must be implicitly added to preserve order of execution (I'm not implying an actual sequence frame is added, this is just how to visualize what's happening). What I don't expect is for the sequence frame to have it's own execution priority. I'll argue an inline VI should be usable in any context since the code contained becomes part of the calling context and should inherit the relevant context properties (priority, preferred execution system).

I'm even more alarmed that the inline code may preserve the preferred execution system. If I use an inline VI which has a different execution setting, am I at risk of introducing unexpected context switches in my code? This would contradict the very reason to make a VI inline to begin with!

Edited July 22, 2016 by mje

[ShaunR]

I'm not quit sure what you are getting at here. You start off with sub-routines and are worried about inline priorities at the end (which I'm pretty sure is ignored and not sure how you tested it wasn't).

An answer to the obvious question though is: Yes it is intended and has always been so. It is a restriction on use in the same way that class methods can only be "Shared" reentrant and not preallocated.

[hooovahh]

I think I know what you are talking about, and I agree.  If I have a VI set to subroutine, I feel like a VI inside it should be allowed to be inlined.  Not sure what the reasoning for the restriction is.

[jacobson]

Turns out this one is on the known issues list (390021 in case the link doesn't take you to it directly)

http://www.ni.com/product-documentation/52698/en/#390021_by_Category

I would have expected that an inlined VI has the same priority as it's caller but I guess not.

[mje]

Fantastic, thanks jacobson.

Shaun, the issue was a subroutine VI can't call inline VIs unless those VIs were also set as subroutine priority. The priority of an inline subVI should make no difference (nor should the execution system for that matter).

Since there's a CAR that describes this, it would be a bug so there's no worry. If it had not been a bug there would be some serious ramifications.

[ShaunR]

8 hours ago, mje said:

Fantastic, thanks jacobson.

Shaun, the issue was a subroutine VI can't call inline VIs unless those VIs were also set as subroutine priority. The priority of an inline subVI should make no difference (nor should the execution system for that matter).

Since there's a CAR that describes this, it would be a bug so there's no worry. If it had not been a bug there would be some serious ramifications.

Yes. I think the confusion is that subroutines aren't really a priority, rather another type of VI. I suppose I know that intuitively so didn't see the relevance when you talked about in-lining and priorities.

Quote

It is important to understand that subroutine classification is not a true priority. “Subroutine” denotes that this VI is no longer a standard VI and that its execution and compilation are radically different from other VIs. Subroutine priority Vis do not have a priority associated with them, and they are never placed into the run queues of LabVIEW. Once all inputs for the subroutine are available, the subroutine will execute immediately, bypassing all run queues. The subsystem associated with the subroutine will stop processing tasks until the subroutine has completed execution. This might sound like a bad idea, but it is not. Having a routine complete execution ASAP is going to get its operation over as quickly as possible and allow ©2001 CRC Press LLC LabVIEW to do other things fairly quickly. Subroutines are a bad idea when very time-intensive tasks need to be done because you will block the run queue for a subsystem for an extended amount of time

Source Chapter 9.9

We should try and get that document int our wiki/blog/articles or whatever-it's is the definitive guid to LabVIEW under the hood.