03-02-2010 02:49 PM
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.
03-02-2010 05:11 PM
@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.
03-03-2010 01:56 AM
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.
03-04-2010 05:08 PM
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
03-04-2010 05:55 PM
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
03-07-2010 10:55 AM
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
03-07-2010 11:29 AM
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.
03-07-2010 02:13 PM
@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
03-08-2010 09:51 AM
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
03-08-2010 10:47 AM
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