timer and Interruptible=Off button callback priority/preemption?

I have a periodic timer with a call back in a GUIDE built GUI app with a button w/call back configured with Interruptible=Off (the timer doesn't have this property). I need to insure that neither call back function (button press or timer) preempts each other, in other words, that a call back that has started to execute will run to completion before the other will run. There doesn't appear to be any semaphore building block functions for the normal non-parallel processing Matlab to handle this manually. Is the timer call-back interruptible by the button call-back?

Answer 1

[Walter Roberson]

The answer apparently depends on your MATLAB version. In newer versions (I'm not sure which one it started in), apparently the timers can interrupt between any two source lines, regardless of whether the callback is marked interruptible or not.

This is not something that I have seen discussed much, or documented: I'm going by my memory of a CSSM thread perhaps a year ago.

[Daniel Shub]

I think that was my cssm thread: http://www.mathworks.com/matlabcentral/newsreader/view_thread/282093#745030

Unfortunately, I did not get any responses. I put in a service request to Mathworks and they made it sound like timers were always asynchronous. At that time I read the release notes back a few versions and there was no mention of a change to timer objects.

I think the change is for the better since the timers run more accurately although it makes the interruptible property and the event queue odd.

[Walter Roberson]

I did see that posting back then, but I got the bit about "between any two lines of code" from a response to some other thread.

[Walter Roberson]

Found some official evidence!

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

Answer 2

[Daniel Shub]

Non-timer graphic callbacks only run when the event queue is flushed. This means as long as you are careful with your timer callbacks to never flush the even queue, your button callback will never interrupt the timer callback.

Preventing the timer callback from interrupting the button callback is harder. Timers run asynchronously (at least since r2010a) and can interrupt any function between any two lines of code (don't ask me what a line of code is and how mex, dll and java fits in since I have asked the Mathworks and they won't tell me). I can think of two ways of preventing the timer callback from interrupting the button callback:

You could also stop the timer while in the button callback and then restart the timer, with the appropriate time shift, when the callback is finished. Figuring out the delay would be a real bear.

I think better would be to add an invisible object to your GUI with a descriptive tag (a toggle would be ideal) whenever the callback is running. If when the timer starts an object with the correct tag exists, then the timer should issue a uiwait.

[Walter Roberson]

Adding and deleting the invisible object could be unnecessary overhead. You could, though, add such an object and have the first line of the button callback set() a property value in the object to non-zero, and the last line of that callback set() it to 0; then, in the timer callback, you could waitfor() that particular property to be 0.

I do not know if this will work, as I do not know about whether timer callbacks are more or less blocking threads that would prevent the button callback from proceeding.

Answer 3

[Stefan Karlsson]

Sometimes I get into the problem that I am in a function that is not interuptible.

An ugly work-around that seems to work (often) is spawn a new temporary timer from the function in question, like so. I would not post this except there seems to be no suggestions on how to address your problems. At least I have a something, so please dont point out how VERY bad this is to do:

%from the function that refuses to be interuptible
start(timer('StartDelay',asLongAsItTakes, ...
            'TimerFcn', {@(~,~,p) HopefullyInteruptibleFunction(p), SomeExtraDataToSend}, ... 
            'StopFcn' ,  @(obj,~) delete(obj)));

[Stefan Karlsson]

"asLongAsItTakes" - a delay time you set as low as you can, high enough that your function will be interuptible "HopefullyInteruptibleFunction" - the function that just takes over execution, and will be interuptible(maybe)