Date: Jan 30, 2013 5:23 PM
Author: Steven Lord
Subject: Re: Making C++ objects persistent between mex calls, and robust.
"Gabri Gwala" <email@example.com> wrote in message
> Many thanks to Oliver Woodford and all the other contributors of this
> effective strategy. Anyway I would like to submit a potential issue when
> using Matlab Parallel Computation Toolbox. In particular i'm trying to use
> this scheme inside a parfor, obtaining a segmentation fault while trying
> to convert a matlab handle in C++ pointer.
> Since this is not a pure Matlab topic, I posted the detailed question on
I'm not an expert in Parallel Computing Toolbox and referring to C++ objects
in MATLAB, but I'm doubtful this will work without significant modification.
Remember that in Parallel Computing Toolbox, workers are separate instances
of MATLAB from the client. There's a reason they have the same icon as the
MATLAB client session in step 3 of the description of a PARFOR loop:
This means that the value representing a pointer to the C++ object in your
client session probably won't point to your C++ object on the workers, and
even if it did (for local workers on the same machine) that memory would
probably belong to the MATLAB client session (possibly leading to the
segmentation violation given in your Stack Overflow posting.)
Think of this like the handle to a figure on the client. When that handle
gets passed to the workers, the workers can't use that handle to affect the
client's figure window -- it's the client's handle!
If your C++ object had a small amount of state, returning a struct array or
cell array from the MEX-file containing the state necessary to reconstitute
the object might be an option (since MATLAB knows how to pass structs
between the client and the workers) but that kind of defeats the purpose of
having a C++ object.
To contact Technical Support use the Contact Us link on