What thread do timers operate in

This question arose from some comments to a previous question: http://www.mathworks.com/matlabcentral/answers/21511-execution-order which refers to another question concerning timers. Instead of hijacking those questions I thought I would ask a new question. The documentation concerning which "thread" a timer operates in and when it can execute its callback seems to be a nightmare.

http://www.mathworks.co.uk/help/techdoc/matlab_prog/f9-38055.html

says: "The specified execution time and the actual execution of a timer can vary because timer objects work in the MATLAB single-threaded execution environment. The length of this time lag is dependent on what other processing MATLAB is performing. To force the execution of the callback functions in the event queue, include a call to the drawnow function in your code. The drawnow function flushes the event queue."

http://www.mathworks.co.uk/support/solutions/en/data/1-2QJ375/index.html?solution=1-2QJ375

says: "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."

I believe (but lack consistent documentation to support) that at least since r2010a timers run asynchronously and can interrupt any function between any two lines of code. I believe this is a change from the original behavior of MATLAB timer objects (introduced back in MATLAB 6.0????), but again cannot find any documentation about this. I also have no idea what a line of code is. For example

x = 1;
y = 2;

is clearly two lines of code, but is

x = 1; y = 2;

one or two lines of code? How do mex, dll and java fit into this? What about compiled built-in functions. What happens when the JIT kicks in?

Answer 1

[Walter Roberson]

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

z = x(1:10) + y(11:20)

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

z = x + CallMe() + y

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.

[Walter Roberson]

Update: a few months ago I tested and found that if you use assignin() to update a variable, then in all the cases I tested the references to the right of the update got the updated value.

This is not promised by MATLAB because of the possibility that the computation might have been delegated to LAPACK or MKL.