Multithreading with mex functions

The documentation of MATLAB suggests that it is OK to multithread with mex functions as long as as the mex API is not used. Multithreading and mex

The link above shows an example of a simple counter. We deploy a software tool developed in MATLAB. Much of the computationally intensive code is written in separately compiled FORTRAN or C modules. The MATLAB GUI just kicks off the executable and returns control to the user. When the executable is finished it writes the output to an ASCII text file. Is it possible to write a mex file that is kicked off when the executable is kicked off? That mex file would just be a while loop checking for the existence of the output file. Once the output file exists, the mex file would interrupt or notify that the results are ready. This would be better then our current implementation where the user clicks to load the results; if the data is not ready it just responds with an error saying to wait a little longer. Does anybody know if this is possible? The link aboves says that the mex API may not be used which includes simple things like mexPrintf. That makes me think that this may not be possible.

Any suggestions?

Answer 1

[Geoff]

I'm not sure if I've interpreted your question correctly, but I think your main problem is working out how to get data back to MatLab asynchronously.

If that is correct, you can start a MatLab timer before firing off your processing app. The timer can poll once per second to check for the existence of the output, then kill itself and fire off some MatLab callback function once the file shows up... You can also do timeouts etc.

-g-

[Paul]

Um...this may be a good idea. Let me give this some thought. This may be the workaround that I have been looking for. Let me experiment on that thought and I will post back if it works. Just for completion, is it possible to trigger a callback from a mex file, a mex file that was being run as a second thread? Although, I am far more inclined to run a timer that triggers a callback than walk down a multithreading mex file path!

[James Tursa]

How is this mex routine "... being run as a second thread"? What, exactly, are you doing to call it that makes it run in a second thread?

[Paul]

A C MEX-file can create a new thread by using _beginthreadex. I didn't actually write this mex file. I just thought that was how we could solve this problem. The workaround proposed by James below is much more appropriate.

[Paul]

I posted a sample of below of code that solved the problem. The timer was what I was looking for. Perfect workaround. Thanks!

Answer 2

[James Tursa]

As I understand it, the executable you plan on running is a completely separate process (is this true?), and as such there are no restrictions on running that separate process while the mex routine is running. In fact, it could be the mex routine itself that kicks off this other executable. The restriction is that within the mex routine itself you cannot call certain API functions (specifically the ones that change memory) within a multi-threaded section of code. You are not doing that.

One piece of advice ... I would have your executable code create two files ... on that is the output data file itself, and another that is a "done" file. Have your executable finish writing to and close the data file, and then have it create the "done" file. Your mex routine then checks for the existence of the "done" file ... at that point you know that the executable has closed the data file and it is avaialable for opening and reading on the MATLAB side.

BUT ... having said all this I have to ask why you need a mex routine for this at all? Why can't you have m-code checking for the existence of this output file?

[Paul]

The executable is a completely separate process. We could use a mex to start the executable but that wouldn't really change much. Interesting point about writing two separate files and I will definitely consider doing that. But how does this mex file that is checking for the "done" file notify/interrupt our MATLAB GUI. The reason we can't have an m file checking is because that would be multithreading which isn't allowed. We wrote a large GUI software in GUIDE. We want the user to have control of the program. If we were allowed to just kick off a separate thread in MATLAB that continuously checked for the "done" file in the background, we would. But as me and my coworkers understand it, that would be multithreading. We just want the some way to interrupt our GUI from the mex file; trigger a callback or something.

Answer 3

[Paul]

Solution to question with some sample code.

function test_OpeningFcn(hObject, eventdata, handles, varargin)
   handles.n = 0;
   handles.t = timer('TimerFcn', {@Checkfordone,hObject},'ExecutionMode','fixedRate', 'Period', 4);
    start(handles.t);

function Checkfordone(timerObject,eventdata,mainHandles)
    handles = guidata(mainHandles);
    handles.n = handles.n + 1;

      directory = dir();
      [m] = size(directory);

      for i = 1:m
          display(directory(i).name)

          if strcmp(directory(i).name,'done.txt')
              display('Output is readty')
              delete(handles.t)
              break
          end
      end
      display(['Timer called:' num2str(handles.n)])

      guidata(mainHandles, handles);

[James Tursa]

readty? :)

Answer 4

[Geoff]

Hey Paul, glad to know that solved your problem. You're still doing it the hard way though! =)

Don't search through a directory listing every poll if you already know the name of the file:

if exist('done.txt', 'file')
  display('Output is ready');
  delete(handles.t);
end

Also, why not just look for the output file instead of a separate 'done' file. Normally, your processing app would write to (for example) 'output.csv.tmp' and then rename to 'output.csv' when complete. That way you picking up partial results.

-g-

[Paul]

Thanks! Good points that I shall use.