MATLAB Answers

timer and Interruptible=Off button callback priority/preemption?

17 views (last 30 days)
Al
Al on 28 Jun 2011
Commented: Stefan Karlsson on 18 Sep 2015
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?

  0 Comments

Sign in to comment.

Answers (3)

Walter Roberson
Walter Roberson on 28 Jun 2011
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.

  3 Comments

Daniel Shub
Daniel Shub on 28 Jun 2011
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
Walter Roberson on 28 Jun 2011
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
Walter Roberson on 17 Nov 2011
Found some official evidence!
http://www.mathworks.com/support/solutions/en/data/1-2QJ375/index.html?solution=1-2QJ375

Sign in to comment.


Daniel Shub
Daniel Shub on 28 Jun 2011
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.

  1 Comment

Walter Roberson
Walter Roberson on 28 Jun 2011
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.

Sign in to comment.


Stefan Karlsson
Stefan Karlsson on 18 Sep 2015
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)));

  1 Comment

Stefan Karlsson
Stefan Karlsson on 18 Sep 2015
"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)

Sign in to comment.

Sign in to answer this question.