LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Darren's Weekly Nugget 03/01/2010


Darren wrote:

In fact, I can't really think of any reason why a subroutine priority VI should *not* be reentrant...if you have deemed a VI worthy of subroutine priority, it wouldn't make sense to have multiple instances of that VI in your code waiting on each other to finish execution.


 

 I am not sure I agree with this reasoning.
 
I have many subroutine priority VIs that are NOT reentrant, e.g. "Action Engine" type VIs. While there is only one instance in memory, they still should have limited call overhead and should run as efficiently as possible. 😉
 
Message 11 of 23
(2,452 Views)

@altenbach wrote:

I am not sure I agree with this reasoning.

 
I have many subroutine priority VIs that are NOT reentrant, e.g. "Action Engine" type VIs. While there is only one instance in memory, they still should have limited call overhead and should run as efficiently as possible. 😉
 

Definitely, a functional global should not be reentrant.  I guess in all my benchmarking over the years, I've never come across one of my own functional globals that was a performance issue...mainly because I don't generally run functional globals in tight loops, nor do I have them do any sort of intense processing within themselves.  But yes, if you have a functional global that you want to squeeze some performance out of, it would surely be an example of a non-reentrant subroutine VI.

0 Kudos
Message 12 of 23
(2,422 Views)

I have to agree with Darren here. I'm definitly a functional global guy, maybe even THE functional global guy, but I had not yet come across a situation where it seemed useful to make them subroutine priority. For me subroutine priority was always limited to relatively simple VI's that either were called numerous times in a tight loop or where performing some serious processing that I wanted to speed up as much as possible. However the last category I often could avoid by rethinking the algorithme and finding one that while usually looking a bit more complex, did the same in a fraction of the time.

 

That said I have to admit that I did learn something from the post Ben made. I was not really aware of the Skip option for subroutine priority VIs and it seems to have its use cases in specific areas.

Rolf Kalbermatter
My Blog
Message 13 of 23
(2,396 Views)

To elaborate a little on what Darren said -

 

If you have a subVI with subroutine priority that is not set to reentrant, and you end up having to wait on another caller, then this causes the thread to sleep and try again when it wakes up.  Since we can't sleep in increments of less than 1ms this is a pretty big overhead for the subVI call.

 

Of course, if you have the "skip if busy" flag set that Ben mentioned, then you won't have this issue.  Just something to be aware of!

 

Greg Stoll

LabVIEW R&D

National Instruments

Greg Stoll
LabVIEW R&D
Message 14 of 23
(2,334 Views)

gregstoll wrote:
If you have a subVI with subroutine priority that is not set to reentrant, and you end up having to wait on another caller, then this causes the thread to sleep and try again when it wakes up.  Since we can't sleep in increments of less than 1ms this is a pretty big overhead for the subVI call.

This is very interesting information. What about a real-time system? Of course we use the "skip if busy" flag for action engines on the RT in time critical code sections if it might be used at a different location as well, but it would be good to know what is the sleep increment on a RT system.

 

Daniel

 

0 Kudos
Message 15 of 23
(2,324 Views)

dan_u wrote:
...., but it would be good to know what is the sleep increment on a RT system.

 

Daniel

 


I don'tknow the answer but I'll do some specualting...

 

I think the Timed loop lets us define that value on a loop by loop basis. When we set-up the Timed Loop we declare timing source and a multiple. Tha is enough to define a interupt routine to wake up the loop. Provided there's nothing stopping the thread from being mark as execuatble. the thread gets scheduled and wakes up.

 

Done specualting.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 16 of 23
(2,247 Views)

gregstoll wrote:

If you have a subVI with subroutine priority that is not set to reentrant, and you end up having to wait on another caller, then this causes the thread to sleep and try again when it wakes up.  Since we can't sleep in increments of less than 1ms this is a pretty big overhead for the subVI call.


 

 
OK, this requires some clarification.
 
Does that mean that if the subVI is NOT subroutine priority, the wait on another caller is faster than 1ms?
0 Kudos
Message 17 of 23
(2,240 Views)

@Ben wrote:

 

... When we set-up the Timed Loop we declare timing source and a multiple. Tha is enough to define a interupt routine to wake up the loop. Provided there's nothing stopping the thread from being mark as execuatble. the thread gets scheduled and wakes up.

 

Done specualting.

 

Ben


This sounds reasonable. For a microsecond (us) timing source on a RT system the "sleep increment" would then be 1us.

But what if the VI is used outside a timed loop, let's say in a communication loop or in a loop timed by FPGA IRQs. I would still expect it to be in the us range. Anyway, I haven't encountered problems with this "sleep increment", it's just curiosity.

 

Daniel

 

 

0 Kudos
Message 18 of 23
(2,227 Views)

altenbach -

 

For subVIs that are not subroutine priority, the wait on another caller is over when the caller gets done - it signals a mutex to wake whoever's next.  This can, of course, be longer than 1ms if the subVI is executing for longer than this, but it can also be shorter.  For subVIs that are subroutine priority, the wait can never be shorter than 1ms.

 

Greg Stoll
LabVIEW R&D

National Instruments

Greg Stoll
LabVIEW R&D
Message 19 of 23
(2,178 Views)

gregstoll wrote: 
...For subVIs that are subroutine priority, the wait can never be shorter than 1ms.

Again, I guess this is for Windows or other non-RT systems, right? What about LabVIEW Real-time? Is Ben's speculation correct?

 

Daniel

 

0 Kudos
Message 20 of 23
(2,163 Views)