Why system function block the timer function in matlab R2018a, but not in R2014a?

Hi all! I meet a problem with timer funcion. I run a code to test timer like this:

function [ ] = ThreadTest( )
    t = timer('StartDelay',0.1, 'TimerFcn',@timerfcn1);
    t.StartDelay = 0.1;
    t.Period = 0.2;
    t.ExecutionMode = 'fixedRate';
    start(t);
    for i=1:2
        disp('Start blocking')
        system('ping 127.1 -n 3 >nul');
        disp('End blocking')
    end
    delete(t)
end
function timerfcn1(~,~)
    disp('I ran!');
end

In R2018a, the result is:

Start blocking
I ran!
End blocking
Start blocking
I ran!
End blocking

while in R2014a:

Start blocking
I ran!
I ran!
I ran!
I ran!
I ran!
I ran!
I ran!
I ran!
I ran!
I ran!
I ran!
I ran!
I ran!
I ran!
I ran!
End blocking
Start blocking
I ran!
I ran!
I ran!
I ran!
I ran!
I ran!
I ran!
I ran!
I ran!
I ran!
I ran!
I ran!
I ran!
I ran!
I ran!
End blocking

It looks like the timer function is blocked by system function in R2018a，not in R2014a. But, why?

[Rik]

Have you tested this on multiple releases to zero in on where the change occurred? I can't find any reference to this in the release notes (searching for either system or timer). What is the behavior when you try to block callback execution with something like pause(3)?

Answer 1

[Rik]

I just ran it on a few releases, and it seems R2015a doesn't block callback execution with system calls, and R2016a does. For good measure I tried pause and uiwait, but neither seemed to block execution of the timer callback in any release I tried.

So the change is either in R2015b or R2016a. As that latter introduced the pause button during execution, as well as live scripts, my money is on that release introducing a change. It is not unreasonable to think that in order to never pause an execution of a system call, they made that uninterruptible, which had the side effect of not being able to execute timer callbacks anymore. Even combing through the release notes again didn't yield a definitive answer.

So my answer is conjecture, but there it is: pausing execution made it so. I'm no Yair Altman, so here my detective work ends. Maybe a staff member will see this thread and respond with the actual reason. If this breaks something for you, you could also contact Support, or check if there is bug report filed (I didn't take the time to comb through several releases worth of bug reports).

I ran the code below to make sure it wasn't secretly running without any graphics updates (which would be even worse news).

function [ ] = ThreadTest( )
clc,global ThreadTest_timerfcn_test_var
%don't use globals, they're a lazy hack
ThreadTest_timerfcn_test_var=0;
t = timer('StartDelay',0.1, 'TimerFcn',@timerfcn1);
t.StartDelay = 0.1;
t.Period = 0.2;
t.ExecutionMode = 'fixedRate';
start(t);
for i=1:2
    disp('Start blocking')
    system('ping 127.1 -n 3 >nul');
    disp('End blocking')
end
stop(t)
delete(t)
end
function timerfcn1(~,~)
global ThreadTest_timerfcn_test_var
ThreadTest_timerfcn_test_var=ThreadTest_timerfcn_test_var+1;
switch ThreadTest_timerfcn_test_var
    case 1
        txt='1st';
    case 2
        txt='2nd';
    otherwise
        txt=sprintf('%dth',ThreadTest_timerfcn_test_var);
end
fprintf('I ran for the %s time\n',txt);
end

[Qing-quan Zhi]

A better code. I do not think it is a bug, but 'timer' in R2014a is more 'multithreaded', which should be inherited by new visions.

[Rik]

This might also be the culprit of a change. And I think I would consider a timer function not being executed a bug.

Answer 2

[Kfir G]

As a workaround you can run the system function using a parallel pool worker. This will not block the timer object callback (tested in 2016b).

In addition, the same issue occured to me when running a .NET function which also blocked the timer callback.

p = gcp();
f = parfeval(p,@system,1,cmd);
res = fetchOutputs(f);