Multithreading with mex functions

7 次查看（过去 30 天）
Paul
Paul 2012-3-15
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?

请先登录，再回答此问题。

采纳的回答

Geoff
Geoff 2012-3-15
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-
  4 个评论
显示 2更早的评论
Paul
Paul 2012-3-16
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
Paul 2012-3-16
I posted a sample of below of code that solved the problem. The timer was what I was looking for. Perfect workaround. Thanks!

请先登录，再进行评论。

更多回答（3 个）

James Tursa
James Tursa 2012-3-15
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?
  1 个评论
Paul
Paul 2012-3-15
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.

请先登录，再进行评论。

Paul
Paul 2012-3-16
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);
Geoff
Geoff 2012-3-19
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-

类别

在 Help Center 和 File Exchange 中查找有关 MATLAB Compiler 的更多信息

标签

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by