skip subroutine if busy for normal priority

[LJHerskowitz]

I want to use the functionality of skip subroutine if busy for a normal priority sub.vi. Is there a way to do it?

This seems like a simple request, but I couldn't find it on the message boards. Sorry if it is there and I missed it.

[GerdW]

Hi LJ,

how do you determine if your "subVI is busy"?

How can it be busy when you want to call it?

Please explain what exactly you are trying to do!

[LJHerskowitz]

I have two parallel loops that call the same functional global variable. If the FGV takes awhile to finish I don't either loop to wait on it.

[crossrulz]

---

@LJHerskowitz wrote:

If the FGV takes awhile to finish I don't either loop to wait on it.

---

1. What do you consider "a while"?

2. What all do you have in a FGV that it would take "a long time"?

#2 is mostly because anything that would take any decent amount of time should not (and likely cannot) be a subroutine anyways.

[LJHerskowitz]

Yes something that takes awhile can't be a subroutine which is my problem. There are a lot of restrictions on what can be inside a subroutine.

I think if I go into details about what is inside the subVI that I want to skip if busy, it will change the conversation to a way to get around skipping a non subroutine if busy. And I'm really just curious if that is possible.

[Ben]

Then I will make it simple and answer "NO". THat VI call option is only available for subroutines.

Alternatives?

Use semaphores?

Ben

[LJHerskowitz]

I haven't played with semaphores before. It looks like semaphores could get the job done. I was thinking there would be a property node to see if the VI was currently busy.

[crossrulz · Accepted solution]

I would say semaphores are your best best here.  Even if you had a property node, that would introduce some interesting race conditions.  What if you check to see if it was busy and then between you checking it was busy and actually calling it, the other process started running the subVI?  You are now stuck in exactly what you are trying to prevent.  And yes, things like this happen.  The specific condition I was told about (took a top-notch developer and one of the top LabVIEW R&D guys hours to find this race condition) involved checking for a queue reference to be valid and then using the queue.  They were actually getting an invalid reference error because the queue was destroyed by another process between the checking for the valid reference and then using the reference.

But the semaphore is simple to use and does the job.