How do I count the number of current running clones of a vi?

[mlwarren]

I have an application that dynamically calls (and forgets) several vi clones.  Once each clone is completed its work, it closes its self.  But during execution there could be a large number of clones executing at any one time.  Is there a way, from LabVIEW, to check how many clones of a vi are currently executing?

Thanks

Matt

[GregFreeman]

I don't think there is, you'll have to have a functional global or something that keeps track. When a VI exits, it decrements the counter, when one starts it increments the counter

[JÞB]

I think this does the job you want.  Let me know.

You might filter the names with a match first to limit the results to your vi of interest

[Ranjeet_Singh]

Hi mlwarren,

                          You see this dynamically called VI, when called by creator vi, calls & forgets. So what i think is you can count how many you created but its not possible to count how many is still running.

One alternate way to use one database application which will read one specific column (Say counter) from specific table (Say dynamicvicounter) in data base. Each time a dynamic vi will be called will read the values from there and increment the value & before terminating will read the value & decrement it.

See in my application database is must. Hence i can use this approach. Please see yours how you can implement this.

Let me know.

Thanks

[tst]

---

Ranjeet_Singh wrote:

One alternate way to use one database application which will read one specific column (Say counter) from specific table (Say dynamicvicounter) in data base. Each time a dynamic vi will be called will read the values from there and increment the value & before terminating will read the value & decrement it.

---

There are several problems with going this way, the biggest of which is that this creates a race condition. If you want to do it properly through a DB, you should use a stored procedure with an inc/dec parameter to update the values. A more minor problem is that this has relatively bad performance and is unnecessarily complicated. The only reasons I can think of for something like this to be desirable is if you wanted the DB to know how many clones there are or if you're working with the DB from more than program at the same time.

Greg's suggestion is much simpler - have an FGV with three actions - increment, decrement, read. The only caveat I can think of with that method is that you need to have at least one call to the FGV in the main hierarchy (a read call) to ensure the FGV never unloads.

[Ranjeet_Singh]

I dont think this will create race condition of any kind. Can you please elobrate how ?

[tst]

---

@Ranjeet_Singh wrote:

I dont think this will create race condition of any kind. Can you please elobrate how ?

---

If you read from a table and then update the table from more than one place, then you could end up with the following situation:

1. A reads, value is 5.
2. B reads, value is 5.
3. A increments and updates, value is 6.
4. B increments and updates, value is 6.

Obviously, after step 4, the value should be 7, but it's 6 because step 2 happened before step 3. That's a race condition. It's the same as having a local variable which you read and increment in more than one place.

In the case of a database, a stored procedure prevents that, because only one caller can execute it at a time, so it's similar to a FGV. In a DB, you could also create a transaction to make several operation atomic, but in any case, this isn't really relevant to the current thread.

[Ranjeet_Singh]

Thats a good explanation but i always try to avoid FGV as i had worst experience with this.

But see the creator is only one & it can call the dynamic VI serially i.e. one after other only. 

In case of database what i mean to say is once one dynamic VI will be called then it will read & close the database. Later  it will be busy with whatever job it is told to do then after completion open the database read the value, increment it & close the database. There is no need to retain the value after read operation.This reading & writing to database is independent operations.

Currently working on diffrent conditions where it will fai;l.. Please see if above algorithm is ok & feedback ?

[Yamaeda]

The easiest must be an external counter of sorts, i'd have a Start and Quit-event sent from the vi that you can listen to and add/remove your counter as needed.

/Y

[tst]

---

@Ranjeet_Singh wrote:
But see the creator is only one & it can call the dynamic VI serially i.e. one after other only. 

In case of database what i mean to say is once one dynamic VI will be called then it will read & close the database. Later  it will be busy with whatever job it is told to do then after completion open the database read the value, increment it & close the database. There is no need to retain the value after read operation.This reading & writing to database is independent operations.

---

If the VIs are called serially, then there's no need to count them, because there will always be 1. The point is that the VIs are running in parallel.

I'm not sure what your point is about the DB, but it still sounds to me like you would have a race condition and in any case, this is just a complicated solution for a very simple problem. Even if you use a DB in the program, there's no good reason to use it for this.