Jump to content

File sharing between to VIs, exe or apps


Recommended Posts

Hi

 

I have at VI running LV8.2.1. It produce two data files.

These two data files has to be moved to at DB-server. I have wrote an exe in LV2012 that run in the tray.

This program look every minute if the other has produced the two datafiles. If they are pressent the exe move them to another place, make some datahandling at them and moven them to the data server.

 

Sometimes the exe can't move the files because the other VI is  in process of making them.

 

Therefor I would like to use a mutex.

I have tried to use .net (and mscorlib.dll) but I can't get it to work.

Here is the code (LV2013):

 

 

post-7489-0-28905400-1385917379_thumb.pn

 

I have made two exes with different names, but when I run them it only one of them that work. It seems that it don't release the mutex.

The other execan only get the mutex when I stop the first exe and close it.

 

hope for some help:-)

 

regards Bjarne

Link to comment

Not a direct answer to your problem, but in similar situations I've solved the issue either by making the file producers use temporary names when they write the file, then rename them afterwards to something that the copier is looking for, or I've made the copier read the modification time/file size, and only copy those that have not changed for a certain time. This only works if the file producers write and close just once, or at a slow pace, and/or if the copiers can extract a valid content and copy that while the file is being updated.

Edited by Mads
Link to comment
Not a direct answer to your problem, but in similar situations I've solved the issue either by making the file producers use temporary names when they write the file, then rename them afterwards to something that the copier is looking for, or I've made the copier read the modification time/file size, and only copy those that have not changed for a certain time. This only works if the file producers write and close just once, or at a slow pace, and/or if the copiers can extract a valid content and copy that while the file is being updated.

Thank you Mads :)

It could be a solution, but I would prefer to use Mutex because in a near future I have another task where I shall syncronize with a DOT_NET program that use mutexes.

 

Regards Bjarne

Edited by Bjarne Joergensen
Link to comment
  • 2 weeks later...

I'm afraid this can't work. You don't know in what OS thread a particular block diagram section runs.

You can't even be sure that the Invoke Nodes WaitOne() and ReleaseMutex() on the same wire are called by the same OS thread.

Manipulating OS threads is unreliable and dangerous in LV.

Consider using lockfiles or TCP/IP instead.

Edited by candidus
Link to comment

Hi candidus

 

Thank you for the reply.
When I was waiting for an answer, a colleague of mine has worked on it too and got it to work in LV.
First off all, there was a little bug in the first snippet I posted. The Parameter "initially owned" has to be set to FALSE.
It works fine if you share the mutex between

Here is the new snippet:

post-7489-0-85969000-1387195487_thumb.pn

 

best regards Bjarne

Link to comment

Hi Bjarne,

 

It works fine if you share the mutex between


In all these cases the code runs in different processes and thus in different threads.

If you try the same in a single application instance this might result in a deadlock.

There is a synchronization object that is thread agnostic: The semaphore.

I would use a semaphore of size 1 instead of a mutex.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.