LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

writing to the same configuration file at the same time

I just realized that I had a few vis that were attempting to write the the same configuration file at roughly the same time.  Based on an informal test, in which I opened the configuration file in two different loops, and wrote to it, then closed it, only one of the two sets of data had been written to the file.  It seems that Labview has nothing built into the configuration file system to ensure sequential access.  

 

    So my first question is, am I mistaken?  Looking at the queue code that is behind the scenes, it looks like this is the case, a read occurs on opening, and a write on closing, and that's it.

 

My second question is, if that is the case, how do people enforce sequential access? As a first pass to fixing my problem with minimal effort, I thought about some sort of semaphore that I would wrap around the opening and closing functions.  Thoughts?  Thanks.

0 Kudos
Message 1 of 5
(3,571 Views)

Did you enable both VI's to append instead of overwrite?

 

I'm not entirely sure whether or not two VIs can have the same file open, but if not:
Use a 'semaphore'. This is used when you have a shared resource, in your case a file, that is used by several programs simultaneously.

This helps to avoid race conditions and ensure no data is lost.

Cory K
0 Kudos
Message 2 of 5
(3,560 Views)

I am using the config file vis so I don't believe that appending is an option.  Also, there are conceivably some instances in which you would be reading and writing to the same keys, in which appending wouldn't make sense.  

 

The option I came up with was to use a semaphore with the name of the requested path before opening the config file, and releasing that same semaphore after writing to the file.  There is a little bit of error handling missing but I think it works.  I've included a test VI which if you replace with the old open and close vis will only write one of the two sections (I think).

 

 undefined

 

undefined

 

 

Note, the other case here just builds onto the arrays in the shift register 

 

 undefined

 

undefined 

 

 

Message 3 of 5
(3,536 Views)

I looked at the config code a bit closer and discovered that errors cause the open and close config vis not to do much.  As such the code above needs a bit of error checking.

 

Main changes include:

- making sure not to add a semaphore when the open config has an error

- I don't wire an error to the close config (there is probably a better way around this), so that I ensure retrieval of the path that I opened (my semaphore name)

- I also don't release empty path semaphores

 

The code still could use a bit of cleanup but it works (I think) ]

 

I've attached some updated code 

0 Kudos
Message 4 of 5
(3,469 Views)

You may be right that the framework needs to protect the underlying object (the file), but the basic answer to your question is simple - don't open two references. If you only use a single reference, your data will be protected. Because the config VIs load and save the entire file, not just the bits you changed, the file is almost sure to lose some of your changes if you open two references to it.

 

I think the correct behavior in this case should be for the Open to return a reference to the already existing data. The simplest mechanism seems to be using the full file path as the queue name instead of an empty name, but it has its own potential problems. There's also an issue with backward compatibility, because some people may rely on the opened data being read from the file, even if it was already changed in memory, although I can't personally see why anyone would do that.


___________________
Try to take over the world!
Message 5 of 5
(3,457 Views)