Possible threadsafe issues using Matlab scripts?

Question

Hi all,
I'm developing an application in Labview 6.1 that makes extensive use
of Matlab scripts.  The application executes the same set of
scripts for multiple data sources, and keeps track of the inputs and
outputs for each data source separately.  I've been noticing that
the application produces the correct results when running only one data
source, but that the results are often incorrect when I run it against
multiple data sources.
I've done some investigation, and have found that all Matlab scripts
share a common memory workspace in Matlab.  That is to say that if
I have ScriptA that takes variable X as an input, and ScriptB that does
not, ScriptB nonetheless has access to variable X in its workspace
(from the last time ScriptA was called).  This doesn't pose a
problem to me directly, but it has made me wonder if there are
potential threading issues in the scripts.
Consider the following scenario with one script and two data
sources.  I'm wondering if this scenario is possible in Labview:
1.  Thread1 calls ScriptA, passing data from SourceX.
2.  During Matlab execution (somewhere in the middle), Thread1 is suspended.
3.  Thread2 calls ScriptA, passing data from SourceY (data have the same variable names, since it's the same script).
4.  Thread2 finishes ScriptA execution uninterrupted with SourceY data.
5.  Thread1 is reactivated, but now the Matlab workspace data has
been replaced with SourceY.  So, Thread1 started with SourceX
data, but finished with SourceY data.
6.  An incorrect result for Thread1 is produced, because the wrong data was processed.
Clearly I could get around this problem with a semaphore, but first I'd
like to know if this scenario can even happen.  Are Matlab scripts
treated as atomic operations in Labview, or can the threads be
suspended midway through execution?
Thanks for your help!
cjb

Answer 1

Hello,
No. LabVIEW will definitely not compile a VI while it's running - I think that would be, even conceptually, impossible.  In fact, some properties (accessed via property nodes) are not editable at run-time for basically that reason, that a recompile would be necessary in order for the affect to take place, and the recompile can't take place at run-time!
It is indeed strange behavior, particularly because it is intermittent (which does hint at a threading issue, or some factor outside the development environment).  Can you try moving the initialization to LabVIEW?  I have attached an example of a so-called functional global variable (a simple code module in this case).  It has two "states" (which are cases) - one is initialize and the other is the "usually executing case."  The initialize case is used to initialize the shift register to an array of 50 doubles, where the other case will compute the running average, min, and max across the 50 most recent random numbers generated.  The 50 data point code module.vi is the code module, and it is called by Use 50 data point code module.vi.  When you run Use 50 data point code module.vi, be sure to toggle the initialize boolean so that the initialize case executes once to allocate and initialize an array with 50 elements; when you toggle it back then it will execute the other case on each iteration, and begin computing the statistics noted by keeping an array with the 50 most recent random data points generated.
I hope this helps and that you are able to incorporate a similar code module into your application to avoid the intermittent errant behavior!
Best Regards, and feel free to post again with updates!
JLS
Best,
JLS
Sixclear
Attachments:
Use 50 data point code module.zip ‏27 KB