0

Some of my friends wrote a program which uses a C program to receive data from network (UDP) and use Matlab to process the data received. Two files viz. 'Data file' and 'Control file' are used to communicate data between Matlab and C. The scheme is as follows.

  1. The C program receives data from network and if 'Control file' contains '0', writes the received data into 'Data file'. After writing the data completely, '0' in the 'Control file' is replaced with '1'.
  2. Matlab program checks for '1' in the 'Control file' continuously and reads data from the 'Data file' as soon as it reads '1' in the 'Control file'. After reading and processing the data, Matlab replaces '1' with '0'in the 'Control file'.

Basically the scheme tries to use the 'Control file' as a 'lock' to safely handle the data in 'Data file'. The data is received continuously in every 1 msec and processing need to be in soft real time.

Though it is claimed that everything is working perfectly, I feel something fishy here. In principle, we should use something similar to semaphore to properly lock the resources....right? What are the pitfalls of this scheme? Is there any better alternate schemes?

EDIT: Now I see that somebody suggested a similar 'quick and dirty' technique at Launch one C++ application from another, and communicate with it

I would like to exactly know why this is a 'dirty' technique? Will it succeed in all situations?

Community
  • 1
  • 1
Sooraj
  • 585
  • 1
  • 6
  • 12
  • If you are locking the file when opening it then the file being locked is similar in nature to a critical region. The question is whether both applications, the C and the Matlab, are both using a file open which locks the file. If they both are then if one has the file open and locked then when the other attempts to open the file, the open will be denied. – Richard Chambers Jan 07 '14 at 18:18
  • 2
    why don't you do the socket IO directly in MATLAB? – glglgl Jan 07 '14 at 19:19
  • I recommend you ditch the whole file-based scheme. Either use the [TCP/UDP/IP toolbox] (http://www.mathworks.com/matlabcentral/fileexchange/345-tcpudpip-toolbox-2-0-6) or port the C program to a MEX file – Peter Jan 07 '14 at 20:08
  • Just a hint, if your software is on the same machine (and thus reads from the same clock) one may consider to specify times at which one program is allowed to access a file, and at which the other is allowed to access the file. (Example: At the start of an even minute: C, at the start of an odd minute: Matlab) This should prevent collisions. – Dennis Jaheruddin Jan 08 '14 at 10:54

1 Answers1

2

You must use file locking in your case (read wiki)

Also you might be interested to see the MEX-Files which provides an interface between Matlab and C, therefore it will enable calling C functions from Matlab. See here and here

phoxis
  • 60,131
  • 14
  • 81
  • 117
  • Thanks for the answer. As you pointed out rightly one should use file locking or some similar mechanism to avoid race condition and dead lock. The application(s) developed using the scheme explained above is working fine for many days. The data rate is also high (8K packets in every 5 msec interval). I was wondering how is it possible, as the scheme does not use any advanced rules like file locking or mutex/semaphores! – Sooraj Jan 10 '14 at 17:09