LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How can I identify different instances of an executable?

I have the "allowmultipleinstaces = True" in the ini file for my standalone apps and want to get some kind of ID for each specific instance.

The reason I need this is that I want to save a temp file associated with each specific instance (the temp file for each instance is updated every now and then and I don't want instance A to overwrite the temp file of instance B).

I could generate a random number or get the start time for each instance and save that as part of the file name, but I wonder whether there is a simple property that I could tap into to do that in a more streamlined manner.

0 Kudos
Message 1 of 15
(3,675 Views)

Probably not a property but a Windows API call would work:

 

DWORD GetCurrentProcessId();

Enclosed VI returns that to you. 

Rolf Kalbermatter
My Blog
Message 2 of 15
(3,662 Views)

Thanks, I'll try that.

0 Kudos
Message 3 of 15
(3,648 Views)

What I've done in situations like this is to use ordinal numbers.  I'm assuming that all of the files will live in a designated folder, and can have a similar file name.  Suppose you decide the data files will be called "My Output Data.N.dat" (where N is an n-digit ordinal number, e.g. 001, 0005, 00006).

 

I'm also going to assume that all of the file writing takes place at the end of the program, and it is unlikely that two instances will try to save files at the same time (where "same time" means within a second or so of each other).  When you are ready to write, have a little routine that finds all of the files of the form "My Output Data.N.dat", isolates all of the "N" numbers, and finds the max.  Add one to it, format it as appropriate (I like to use leading zeros, adjusting the width depending on how many of these files I expect to have to carry around) and use it as the file name.

 

This has a number of advantages.  First, you can probably code this to minimize the probability of a name clash.  Second, you have "control" of the name, and it has a "natural meaning" (it tells you something about how many of these files you have, and their relative order).  In this sense, it is "more logical" than a random number name (though that would work fine for temporary files).  An alternative would be to use something like a time stamp, but you might need quite a few otherwise-meaningless characters in order to make name-uniqueness likely.

 

Bob Schor

 

 

 

Message 4 of 15
(3,630 Views)

 


@Bob_Schor wrote:

What I've done in situations like this is to use ordinal numbers.  I'm assuming that all of the files will live in a designated folder, and can have a similar file name.  Suppose you decide the data files will be called "My Output Data.N.dat" (where N is an n-digit ordinal number, e.g. 001, 0005, 00006).

  


I was thinking of a strategy like this, but I could not exclude completely that two instances would write their temp files simultaneously.

The saves are for backup files, and are intended to be replaced every minute or so.

Message 5 of 15
(3,619 Views)

That's why they invented the Mutex (which I believe LabVIEW calls a "semaphore").  I'm not 100% sure how to implement this using independent executables, but something similar to a Mutex should be codable ...

 

BS 

0 Kudos
Message 6 of 15
(3,596 Views)

Under Unix, interprocess mutexes are usually solved with files in well known locations. However implementation of this has some pretty tricky considerations in order to prevent race conditions. There are certain Unix/Posix file IO functions that are guaranteed to create a file as an atomic operation or fail if the file already exists. But doing that on LabVIEW level with the standard file IO functions would be more complicated.

 

If the only concern is the creation of a unique temporary file however, you can use the function in vi.lib/Utility/librarian.llb/Temp Filename.vi which will generate a random file name until it does not conflict with an existing filename. However this one is pretty crude and doesn't guarantee that two different processes could by accident attempt to create the same time and seemingly succeed. An additional check would be to use the deny flags when attempting to create the file as well as the open mode to only create a file the first time you create a new file, instead of open or create, and retry with a new filename until it doesn't fail.

 

However using the process ID in the filename is another sure way to guarantee no collision. At any one time there can always only be one process in memory with a specific process ID.

Rolf Kalbermatter
My Blog
0 Kudos
Message 7 of 15
(3,574 Views)

rolfk wrote:

 

However using the process ID in the filename is another sure way to guarantee no collision. At any one time there can always only be one process in memory with a specific process ID.


The only drawback is that it is not portable from system to system without a rewrite.

In my case, I don't care, but from a LabVIEW point of view, it would seem that having a way to identify different "clones" of the same application (by tapping into process ID requests under the hood?) would be useful beyond my specific use case.

 

0 Kudos
Message 8 of 15
(3,533 Views)

@X. wrote:

rolfk wrote:

 

However using the process ID in the filename is another sure way to guarantee no collision. At any one time there can always only be one process in memory with a specific process ID.


The only drawback is that it is not portable from system to system without a rewrite.

In my case, I don't care, but from a LabVIEW point of view, it would seem that having a way to identify different "clones" of the same application (by tapping into process ID requests under the hood?) would be useful beyond my specific use case.

 


Except that the allowMultipleInstances=True ini key is a semidocumented feature to circumvent a mechanisme that was originally put into LabVIEW to disallow multiple clones being started, which made the need for retrieving process IDs pretty unnecessary! Also process IDs are in fact a OS specific low level feature, that can be argued to have no place in a high level multiplatform system like LabVIEW.

Rolf Kalbermatter
My Blog
0 Kudos
Message 9 of 15
(3,523 Views)

@rolfk wrote:

 

Except that the allowMultipleInstances=True ini key is a semidocumented feature to circumvent a mechanisme that was originally put into LabVIEW to disallow multiple clones being started, which made the need for retrieving process IDs pretty unnecessary! Also process IDs are in fact a OS specific low level feature, that can be argued to have no place in a high level multiplatform system like LabVIEW.


It seems pretty well documented to me: http://digital.ni.com/public.nsf/allkb/AB268878693EF4B586257037004A6725

 

0 Kudos
Message 10 of 15
(3,519 Views)