multiple open file at different location

[jyang72211]

I have the same exe at multiple stations.  Mainly, they will stay idle.  When a user click run on any given station, the exe will run the open/create/replace file node to open a specific file (on a server) and then write to it.  I am afraid that mutliple user will run the exe at each station at the same time, which will result in an error (It thought, but may not be true anymore).  I did some experiment (see attached), and I realized that following:

1. I always thought that if I have a file open (double-click on the file) and try to read the file with LabVIEW, I would get an error in LabVIEW.  Apparently, that's not true.  Doesn't someone have the exclusive right to write?  What's going on?

2.  it seems that it doesn't matter if I have a file open for write or not.  I will be able to write to the file in LabVIEW anyway.  Is this true?  

3.  If you run the attachment for the first time (file not created yet), you will get an error 10.  I am not sure why, since I chose the open or create operation, so not having the file shouldn't be a problem.  The problem will go away completely if you use replace or create.  Why is that?  

[Christian Mergl]

Please have a look at this KB.

Christian

[jyang72211]

Thanks!  However, this doesn't answer some of my question.  No only does the open file node not generate any error.  It actually allows me to write to a file that is opened.  I want to understand why.  

[MilanR]

Hi jyang72211,

If you are interested in a more theoretical understanding of this topic, the File locking wikipedia entry provides a scenario of how race conditions like the one you are concerned about may occur. Because your files are hosted on a server accessed over the network by multiple machines, the KB specified by Christian_M would be the solution needed to control file access for the system description you provided. It is similar to the case of opening the same word document multiple times on the same machine. Opening the same file multiple times is not prevented and the order of saving matters.

The example VI provided has a race condition in that the open/create/replace vi execution can occur in different orders so the behavior is not fully deterministic due to the parallelism of execution. This is why semaphores and other mechanisms are needed to provide controlled access. If the vi is run in highlight execution mode (pressing the lightbulb in the toolbar) the behavior is consistent because sequential execution is enforced, but if running the vi normally with full parallelization sometimes I receive the error and sometimes I don't receive the error when testing the VI.

Does this help to clarify your question?

[jyang72211]

Below are my previous questions refined plus a few more questinos.  

1. Is it true that even if a file is open, LabVIEW can still open it and make changes to it with no error from the nodes?  I understand that race condition will occur.   

2.  If you run the attachment for the first time (file not created yet), you will get an error 10.  I am not sure why, since I chose the open or create operation, so not having the file shouldn't be a problem.  The problem will go away completely if you use replace or create.  Why is that?  Please see my previous post for attachment.

3. I tried the tempory file approach for looking while writing to a log file (check if a temp file exist -> create temp file for file locking -> write to log file -> delete temp file).  I don't like it very much, since I have to open and close another file in my program, and that slows down the response time.  How do I speed it up?  Or is there a better way?  

[MilanR]

Hi jyang72211,

I would be glad to work with you to help clarify your questions! I will just go through and try to address them one-by-one.

1. Is it true that even if a file is open, LabVIEW can still open it and make changes to it with no error from the nodes? I understand that race condition will occur.

Yes that is true, in the KB provided by Christian_M it states that LabVIEW does not generate an error or warning if trying to open a file that is already open, so it is then possible to perform writes from two different references without an error occurring.

For demonstration of this I made a small adjustment to your example file that removes the race condition for opening the file and shows that no error is generated when the file is opened twice. Disclaimer: This is NOT a recommended approach for accessing the same file from multiple places within an application or from multiple applications, please see the KB provided by Christian_M for recommended approaches.

2. If you run the attachment for the first time (file not created yet), you will get an error 10. I am not sure why, since I chose the open or create operation, so not having the file shouldn't be a problem. The problem will go away completely if you use replace or create. Why is that? Please see my previous post for attachment.

As mentioned in the previous post, with my testing sometimes this error is received on first execution and sometimes it is not. This is because of a race condition caused by the File opens executing at the same time. I have modified the VI to prevent this race condition and I no longer receive this error on opening the file using the "open or create" operation.

3. I tried the temporary file approach for looking while writing to a log file (check if a temp file exist -> create temp file for file locking -> write to log file -> delete temp file). I don't like it very much, since I have to open and close another file in my program, and that slows down the response time. How do I speed it up? Or is there a better way?

Fundamentally you have to share information between machines that signifies that the file is in use with a flag. There are many networking mechanisms that enable this.
One possibility is to use shared variables to share a flag between machines for when the file is inaccessible. There is a great DevZone on how to use shared variables.

Another possibility is to use the TCP/IP stack to create your own custom protocol, although this is probably a greater amount of complexity than is needed for this application. Shared variables provide a simple and useful abstraction for this type of application of sharing a flag over the network.