Thread Subject: copy-on-write with MEX files

I'm trying to understand if there is a difference in the
way copy-on-write is implemented for MEX functions as
compared to Mfiles.

My understanding is as follows. As part of the copy-on-
write system, MATLAB will pass input data by reference to
an Mfile function if the function performs read-only
operations on that data. Otherwise, it will pass the data
by value.

However, when it comes to MEX functions, the MATLAB
interpreter obviously cannot know the contents of the
function and cannot determine whether the operations it
will perform are read-only or otherwise. If MATLAB wanted
to have all the same safety nets as for Mfiles, it would
have to always pre-duplicate the input data and send that
to the MEX function instead (effectively passing the data
by value).

One reason for doing it this way would be to ensure that if
the MEX file crashes, the input data would remain unaltered
in the caller workspace. This will be true for Mfiles, and
the MATLAB software designers may have wanted it to be true
for MEX files as well.

On the other hand, if data is always passed by value, it
would obviously reduce the possibilities for computational
efficiency that people are usually interested in using MEX
files to obtain.

In any case, I have several colleagues who believe MEX
files always receive input by value. Can anyone resolve
this?

"Matt " <mjacobson.removethis@xorantech.com> wrote in
message <g68b41$cu8$1@fred.mathworks.com>...
>
> I'm trying to understand if there is a difference in the
> way copy-on-write is implemented for MEX functions as
> compared to Mfiles.
>
> My understanding is as follows. As part of the copy-on-
> write system, MATLAB will pass input data by reference to
> an Mfile function if the function performs read-only
> operations on that data. Otherwise, it will pass the data
> by value.
>

No. MATLAB does not pre-parse the m-file to determine if an
input variable is changed. MATLAB *always* passes the
variables by reference. Once inside the m-file, if the input
variable is changed, *then* MATLAB makes a copy. That is the
copy-on-write behavior.

> However, when it comes to MEX functions, the MATLAB
> interpreter obviously cannot know the contents of the
> function and cannot determine whether the operations it
> will perform are read-only or otherwise. If MATLAB wanted
> to have all the same safety nets as for Mfiles, it would
> have to always pre-duplicate the input data and send that
> to the MEX function instead (effectively passing the data
> by value).
>
> One reason for doing it this way would be to ensure that if
> the MEX file crashes, the input data would remain unaltered
> in the caller workspace. This will be true for Mfiles, and
> the MATLAB software designers may have wanted it to be true
> for MEX files as well.
>

There is no safety net for MEX files. There is no
copy-on-write behavior for MEX files. The variables are
passed by reference to the MEX file, same as an m-file. If
you change an input variable in a MEX file, then the
original is changed (as well as all other variables that
share the same data memory). This can mess up the workspace
of course, which is why you see warnings to never do this in
the doc. However, it *is* safe to do if you *know* that the
data memory is not shared with another variable. This can be
tricky and is not recommended unless you really need to
(e.g., very large variables that you don't want duplicated).

> On the other hand, if data is always passed by value, it
> would obviously reduce the possibilities for computational
> efficiency that people are usually interested in using MEX
> files to obtain.
>
> In any case, I have several colleagues who believe MEX
> files always receive input by value. Can anyone resolve
> this?
>

Variables are never passed by value to m-files or MEX files.

James Tursa

"James Tursa" <aclassyguywithaknotac@hotmail.com> writes:

> "Matt " <mjacobson.removethis@xorantech.com> wrote in
> message <g68b41$cu8$1@fred.mathworks.com>...
>>
>> I'm trying to understand if there is a difference in the
>> way copy-on-write is implemented for MEX functions as
>> compared to Mfiles.
>>
>> My understanding is as follows. As part of the copy-on-
>> write system, MATLAB will pass input data by reference to
>> an Mfile function if the function performs read-only
>> operations on that data. Otherwise, it will pass the data
>> by value.
>>
>
> No. MATLAB does not pre-parse the m-file to determine if an
> input variable is changed. MATLAB *always* passes the
> variables by reference. Once inside the m-file, if the input
> variable is changed, *then* MATLAB makes a copy. That is the
> copy-on-write behavior.

To expand on this a little, there is a C-level function in MATLAB that
"unshares" a variable. Internal functions in MATLAB that write to
variables (subsasgn, etc) call this function before writing to the
memory. Function parameters are exactly like assignments in the same
workspace. Nothing happens at function call time except a shared-data
assignment.

>> However, when it comes to MEX functions, the MATLAB interpreter
>> obviously cannot know the contents of the function and cannot
>> determine whether the operations it will perform are read-only or
>> otherwise. If MATLAB wanted to have all the same safety nets as for
>> Mfiles, it would have to always pre-duplicate the input data and send
>> that to the MEX function instead (effectively passing the data by
>> value).
>>
>> One reason for doing it this way would be to ensure that if
>> the MEX file crashes, the input data would remain unaltered
>> in the caller workspace. This will be true for Mfiles, and
>> the MATLAB software designers may have wanted it to be true
>> for MEX files as well.
>>
>
> There is no safety net for MEX files. There is no
> copy-on-write behavior for MEX files. The variables are
> passed by reference to the MEX file, same as an m-file. If
> you change an input variable in a MEX file, then the
> original is changed (as well as all other variables that
> share the same data memory). This can mess up the workspace
> of course, which is why you see warnings to never do this in
> the doc. However, it *is* safe to do if you *know* that the
> data memory is not shared with another variable. This can be
> tricky and is not recommended unless you really need to
> (e.g., very large variables that you don't want duplicated).

The MEX API clearly defines the input variables as "const". You can
defeat this, of course, but you shouldn't unless you're willing to
really dig into what happens at this level, and need that extra 5%
efficiency for some in-place computation.

-Peter

OK. That does clear it all up!

Much obliged to you both.

Peter Boettcher <boettcher@ll.mit.edu> wrote in message <muyd4l35v1v.fsf@G99-Boettcher.llan.ll.mit.edu>...

> To expand on this a little, there is a C-level function in MATLAB that
> "unshares" a variable. Internal functions in MATLAB that write to
> variables (subsasgn, etc) call this function before writing to the
> memory.

Maybe you can help me clarify how this works. Suppose the following:

X = ones(10, 1);
Y = X;
Z= X;
X(1) = 2;

Based on my understanding and the tests I have done, it seems like the following happens:

Memory is allocated and X is set to point to address a1.
Y is set to point to a1.
Z is set to point to a1.
A deep copy of the memory pointed by X, Y, and Z is performed (address a2), Y and Z are changed to point to a2, and a new value is assigned to the location pointed to by X(1).

However, I suppose its possible that the situation is reversed and X points to a2 while Y and Z continue to point to a1. However, this seems like it would introduce a number of problems with sharing data between the MATLAB and MEX workspaces.

Can you clarify if the behaviour I have described is correct?

Thanks!

"Ryan Ollos" <ryano@physiosonics.com> wrote in message <ggoads$sqr$1@fred.mathworks.com>...
> Peter Boettcher <boettcher@ll.mit.edu> wrote in message <muyd4l35v1v.fsf@G99-Boettcher.llan.ll.mit.edu>...
>
> > To expand on this a little, there is a C-level function in MATLAB that
> > "unshares" a variable. Internal functions in MATLAB that write to
> > variables (subsasgn, etc) call this function before writing to the
> > memory.
>
> Maybe you can help me clarify how this works. Suppose the following:
>
> X = ones(10, 1);
> Y = X;
> Z= X;
> X(1) = 2;
>
> Based on my understanding and the tests I have done, it seems like the following happens:
>
> Memory is allocated and X is set to point to address a1.
> Y is set to point to a1.
> Z is set to point to a1.
> A deep copy of the memory pointed by X, Y, and Z is performed (address a2), Y and Z are changed to point to a2, and a new value is assigned to the location pointed to by X(1).
>
> However, I suppose its possible that the situation is reversed and X points to a2 while Y and Z continue to point to a1. However, this seems like it would introduce a number of problems with sharing data between the MATLAB and MEX workspaces.
>
> Can you clarify if the behaviour I have described is correct?
>
> Thanks!

I found some info in another newsgroup post, where someone noted that you can type 'format debug' and get the memory address location printed to the terminal.

It seems to be the case for my example that Y and Z continue to point to a1, while X points to a2. I suppose this is a computational advantage because it changes a fewer number of pointers.

Dear Matt!

> I'm trying to understand if there is a difference in the
> way copy-on-write is implemented for MEX functions as
> compared to Mfiles.

Look into the file matrix.h (in <matlabroot>\extern\include\). There you find the code for array_access_inlining, which shows the implementation of a Matlab array.
Besides the obvious fields as pointer to real and imaginary part of the data, number of dimensions and size of an element, you find a bunch of flags and several pointers to void called "reserved", "reserved1" etc.
It might be easy to find out, which field is the vector keeping the dimensions, the class and the perhaps the name of the array. But a reverse-engineering of the bunch of flags wil be impossible and as far as I know: this might be conflicting with the terms of use.

Sometimes one really needs passing variables by reference to a MEX file and changing the original memory - i.e. if your data occupy 50% of your available RAM: Then just create a new class, which works with memory persistently stored in a MEX file: see mexMakeMemoryPersistent. Then the object does not contain the data itself, but just a pointer to it and passing by reference is performed implicitly. A drawback is, that the complete processing must be done in MEX functions.

Kind regards, Jan