Matlab timer is not executed asynchronously

Hi, I am developing a Matlab UI program where the callback of a button pressed might take lots of time to process. So I basically want the callback to be executed asynchronously and ask the UI to update the callback result when it is ready.

Some documents suggests doing this by using Matlab timer callback but I found the callback is still not executed asynchronously.

Here is a simple code for testing:

function [ ] = ThreadTest( )
    t = timer('StartDelay',0.1, 'TimerFcn',@utilityFcn);
    start(t);
    for i=1:10000;
        pause(0.1);
        fprintf('x');
    end
end

function utilityFcn(src,evt)
    % some lengthy calculation/update done here
    for i=1:100;
        temp = rand(1000,1000)*rand(1000,1000); 
    end
    fprintf('done');
end

I expect this program will continuously print 'x' in every 0.1 sec and there will be a print of 'done' when the callback is finished. However, in this example, the 'x' is only printed when the all lengthy computation is done (i.e., always printed after the 'done' is printed)

Answer 1

[Walter Roberson]

The details are more complicated than Jan indicates. Multiple threads are used in some cases.

https://www.mathworks.com/matlabcentral/answers/21537-what-thread-do-timers-operate-in

https://www.mathworks.com/matlabcentral/answers/94884-is-there-variable-access-synchronization-between-matlab-main-execution-thread-and-spawned-java-threa

"For example, a timer object is in a different thread than the MATLAB main thread. But it cannot interrupt a single MATLAB command i.e. a variable copy command.

A block of MATLAB code can be interrupted by a timer object. Thus if a block of code operates on a variable, there is a possibility of data corruption.

However, Just-in-Time compilation (JIT) can execute several lines of code all at once in certain circumstances, in which case the timer will not be able to interrupt execution. If the interruption must happen in a particular place, a DRAWNOW command will ensure that one can occur. Otherwise, the DRAWNOW is not needed."

In your example possibly everything in your "for" loop got compiled into a single JIT block.

We are positive that internal calls to BLAS or LINPAK cannot be interrupted by timers. We believe (but are not certain) that no one source line of MATLAB code can be interrupted by timers. We are rather less certain about when multiple-line blocks can be interrupted by timers.

[Yu-Chih Tung]

@Walter Thank you for the explanation. I think I find a workaround by using C++ socket (layered by mex) and the GUI interruptible callback.

I find the GUI interruptible callback can absolutely make a "kind of" async processing even Matlab is a single-thread process. I believe it is achieved by preempting "seemly-concurrent" processings. However, the Matlab socket will still block everything. Using the c++/mex socket can solve this problem and the the c++ socket write/read is thread-safe.

I am not sure if it is the best solution yet, but I am working on it. I will post the final code after my test.

[raym]

Even a timerfunc of single line: system('notepad') will block the cmd window of matlab.

Answer 2

[Jan]

Note what would happen, if the timer would be asynchronous:

function [ ] = ThreadTest( )
  global x
  t = timer('StartDelay', 1, 'TimerFcn', @utilityFcn);
  start(t);
  for i = 1:100;
      pause(0.1);
      x = x + 1;
      fprintf('%d ', x);
  end
end

function utilityFcn(src,evt)
  global x
  x = x + 1000;
end

Now there would be a racing condition between the main thread and the timer callback: The main thread gets the value of x and increases it by 1. If now the timer thread does exactly the same, it is not predictable which thread writes back the new value at first.

Unpredictable states are extremely bad for programming. And therefore Matlab is single threaded currently. [EDITED: added] This means that there cannot run code asynchronously, neither as a timer callback nor by using C-Mex tricks like mexCallMATLAB from several threads.

But what about parfor loops? [EDITED end]

The example might look artifical, but the real world code is much more complicated and collisions are harder to find, but this does not mean that they do not occur. It can concern persistent variables, ApplicationData of GUI objects, the state of mutual exclusive radio buttons, writing to files, etc.

[Yu-Chih Tung]

Hi Jan,

I know racing condition might happen for any multiple-thread programming but it doesn't answer the question. Are you suggesting that timer is not able to be called asynchronously? If so, how can I have an asynchronous call?

[Jan]

@Yu-Chih Tung: Matlab is single-threaded. You cannot run code asynchronusly. If you try this using tricks in the MEX interface, Matlab crashs as expected.

So my answer is: This will not work. Matlab is not prepared to handle e.g. the mentioned racing conditions in its internal functions.

parfor loops run asynchronously. I do not have teh parallel processing toolbox, so wait if anybody else posts a corresponding solution.