How to run .m files in one thread from an app running in a different thread so that I can interact with the app during .m file execution?

I have an app that I have made programmatically (without appdesigner) that frequently calls already existing functions located in .m files when I click certain buttons. Currently, the app itself and the functions it calls are all run in the foreground. However, these functions can take a long time to execute (several hours), during which time I cannot interact with the app (because callbacks won't execute until after the functions finish running).

The documentation on backgroundPool and parfeval is a bit confusing to me. Is there a way to make the app run on one pool, and the functions in the .m files to run on another thread? I have access to the Parallel Computing Toolboox. Or, would it require running two instances of MATLAB simultaneously? Is it possible to share data across two instances of MATLAB?

Answer 1

[Raymond Norris]

@Mitchell Tillman you might consider refactoring the code so that the callbacks call parfeval with backgroundPool, but keep in the app running on MATLAB's main execution thread. For instance instead of

function PlotCallback(..)
    data = ..
    plot(data)
end

call

function PlotCallback(...)
    % Spawn a thread to handle the plotting
    parfeval(backgroundPool,@plotdata, ..)
    % Come back immediately to free up the App
end

I'm leaving an awful lot out here, but hopefully you get the idea

[Walter Roberson]

background pools support a subset of functions supported by Parallel Computing Toolbox, but background pools are more efficient at sharing memory with the main thread in the case where you can use them.

Neither background pools nor standard parallel pools can directly send anything to the display. pool members can never communicate directly with each either.

Communicating between pools and the client is a bit clumsy, but possible using parallel.pool.DataQueue

You can even do things such as plot on a worker (which will not be displayed), and use a parallel data queue to send the graphics object to the client which would then display the object.

[Raymond Norris]

@Walter Roberson's right, graphics will be an issue for backgroundPool.

[Mitchell Tillman]

Thanks for your answers, but I think that not being able to plot or even display text in the command window is a dealbreaker for my use case.

As an alternative, I’m thinking that two separate instances of MATLAB might do the trick, but I’m not sure if what I’m envisioning is possible.

Let’s say I open one instance of MATLAB and run the function that opens the app. Ideally, I’d like this function to start a second instance of MATLAB that is headless (-nodisplay or the supported Windows equivalent), but that still displays the app in headless mode. Then, I’d like to be able to use the app in MATLAB instance #2 to run functions in MATLAB instance #1. This would allow all the benefits of parallelism, and plotting as well. Finally, the 2nd instance of MATLAB would close when the app closes using its DeleteFcn. Is something like this functionality currently possible?

[Walter Roberson]

@Mitchell Tillman

When you have parallel pool, or background thread pool, then the only way the workers can display graphics is to send data to the client for the client to display, or send graphics objects to the client for the client to display.

When you have separate MATLAB instances, then the above methods are still possible (if you use one of several ways to send data between processes.) You also gain the possibility that the second instance is running on the same display and so can display graphics directly in its own area (but not cannot control graphics for the first MATLAB instance.) Running on the same display typically involves the second MATLAB running on the same host, but if you are using Linux with X-Windows then in theory they could be remote; likewise you could in theory be running a remote desktop type of application to display graphics created on a different host.

There are no mechanisms provided to tightly couple multiple MATLAB instances -- at least none other than parfor / spmd / parfeval / batch