That Solution is about as explicit as such things get:
But in the case of a block of code:
y=x(1:500000);
y=[y x(500001:1000000)];
a timer shot can occur after the first statement and change "x".
Thus, timers can interrupt between statements.
I think the key here is "statements": multiple commands on the same line are multiple statements.
I speculate that any one call to "builtin" routines (or compiled library routines) (or mex routines) cannot be interrupted: that only when the call gets to the threaded interpreter can an interrupt occur.
What I do am unsure of at the moment is what happens if you have multiple compiled calls in a single line, such as
Then if the subsref call to x is [eventually] atomic and the same with the subsref to y, then could there be an interrupt between the time the subsref to x finished but before the subsref to y started? And could that interrupt change y -- or do x and y get locked in when the assignment statement starts and unlocked afterwards?
Which reminds me, of something I have never experimented with: if you have an expression
and CallMe does an assignin('caller','y',...) then which y value will be used in the addition? If we hypothesize variable-change locks as in the end of the previous paragraph, then it would not make sense for there to be an opportunity for CallMe() to change y, so if CallMe() can change y during the expression such that the new y was used, then I would tend to take that as evidence that statement-level change timer change locks do not exist.
Best Answer