MATLAB Answers

0

Calling function described in actxcontrol inside parfor loop

Asked by Aleksandr Averchenko on 10 Sep 2019
Latest activity Commented on by Edric Ellis
on 11 Sep 2019
Hello everyone!
I have a problem with organizing parfor loop for simultanious computations
Here is a part of my code:
poolobj=gcp;
addAttachedFiles(poolobj,{'APT_GUI_SYS.m','actxcontrol.p'});
parfor t=1:2
if t==1
y=function1(x);
end
if t==2
SC_Enable(h1,0);
end
end
The function SC_Enable is defined through attached script. It doesn't exist inside the script as it is, but this function is a component of actxcontrol
the error is the following:
An UndefinedFunction error was thrown on the workers for 'SC_Enable'. This
might be because the file containing 'SC_Enable' is not accessible on the
workers. Use addAttachedFiles(pool, files) to specify the required files
to be attached. For more information see the documentation for
'parallel.Pool/addAttachedFiles'.
Caused by:
Undefined function 'SC_Enable' for input arguments of type 'double'.

  0 Comments

Sign in to comment.

2 Answers

Answer by Guillaume
on 10 Sep 2019
Edited by Guillaume
on 10 Sep 2019

I'm not entirely sure what you mean by "It doesn't exist inside the script as it is, but this function is a component of actxcontrol". Possibly, you mean that SC_Enable is a method of the activex control MGMOTOR.MGMotorCtrl.1.
In which case, the call could be rewritten as:
h1.SC_Enable(0);
It remains to be seen whether h1 is the same h1 as used by your script. It's never a good idea to use global variables and, not having the parallel toolbox, I'm not sure how it handles global variables. You need to make sure that h1 is actually a reference to your control within the parfor. At the moment, it looks like matlab thinks it's a double.
As I said, I don't have the parallel toolbox, so I don't know how exactly it works, but I assume it creates multiple threads from a parfor. If so, it's unlikely you'll be able to interact with a control from multiple threads. The UI framework of Windows, Linux, etc. (nothing to do with matlab) will only work properly when UI elements are modified from the main thread, not from parallel threads. Attempting to do so may result in a crash.

  1 Comment

Yes, you are right about "Possibly, you mean that SC_Enable is a method of the activex control MGMOTOR.MGMotorCtrl.1."
So, i have already tried
"In which case, the call could be rewritten as:
h1.SC_Enable(0);"
but it haven't worked. In this case i have a different error:
'Dot indexing is not supported for variables of this type.'

Sign in to comment.


Answer by Edric Ellis
on 11 Sep 2019

Firstly, you are declaring h1 to be a global variable in your APT_GUI_SYS script. That will not work as you expect - workers are separate MATLAB processes, and do not synchronise their global workspaces.
Secondly, the type of h1 is actxcontrol - I strongly suspect that you cannot save/load these. To send a variable into a parfor loop, it must support being saved and loaded (parfor uses a process similar to save/load to transfer variables to workers - but it doesn't create files on disk). What I guess is the problem is that on the workers, h1 is ending up as [], which is causing the problems.
What I suspect you want to do is use a parallel.pool.Constant to create the actxcontrol on each worker process, using a process similar to the "function handle" example on the doc page. However, even that might not be enough, since I notice you're building the actxcontrol with a figure handle. Workers executing the body of a parfor loop cannot (directly) modify the contents of a figure showing on your desktop client MATLAB.

  4 Comments

Show 1 older comment
I must admit I'm afraid I missed some of the details from your answer - but there are ActiveX controls that are useful for stuff other than UI interaction (for example interacting with Excel or similar). Those sometimes can be made to work correctly with parfor, but it's not always straightforward.
It's not always the case, but there are situations where producing graphics inside parfor can be useful - but typically this involves producing plots and then exporting them to file.
Interaction with excel is with actxserver not actxcontrol. As far as I know COM objects created with actxcontrol are always UI elements.
You can indeed use COM objects (created with actxserver) in background threads but I don't think that's applicable here. In any case, unless the COM server is built with multithreaded apartment there's probably no benefit in multithreading the COM calls, it will all be marshalled to a single thread. If anything performance will degrade significantly.
but there are situations where producing graphics inside parfor
I assume these are not rendered on screen (by the worker)?
Ah, OK - not really something I know much about I'm afraid. That's right, graphics from workers are not rendered on-screen.

Sign in to comment.