Path: news.mathworks.com!not-for-mail
From: <HIDDEN>
Newsgroups: comp.soft-sys.matlab
Subject: Re: Modifying MEX arguments in place?
Date: Thu, 14 Feb 2008 07:01:06 +0000 (UTC)
Organization: Boeing
Lines: 73
Message-ID: <fp0ovi$qf2$1@fred.mathworks.com>
References: <fp0fqv$3gd$1@fred.mathworks.com> <fp0gke$gqq$1@canopus.cc.umanitoba.ca>
Reply-To: <HIDDEN>
NNTP-Posting-Host: webapp-05-blr.mathworks.com
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Trace: fred.mathworks.com 1202972466 27106 172.30.248.35 (14 Feb 2008 07:01:06 GMT)
X-Complaints-To: news@mathworks.com
NNTP-Posting-Date: Thu, 14 Feb 2008 07:01:06 +0000 (UTC)
X-Newsreader: MATLAB Central Newsreader 756104
Xref: news.mathworks.com comp.soft-sys.matlab:451317



roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote in
message <fp0gke$gqq$1@canopus.cc.umanitoba.ca>...
> 
> I know little about MEX, but generally speaking, the memory
> that you are handed for any Matlab variable might be shared
> with other Matlab variables due to the "lazy copy" behaviour.
> When you change the memory in-place, you would have
changed those
> other variables too.

That is the danger, of course.

> The columns you see might be linked to columns of other
variables.

I suppose that is possible, but I seriously doubt it. When
you create a variable, MATLAB grabs memory from the heap to
do it. It has to grab the data memory as one contiguous
chunk in order for all of the other things you do with
variables to work properly, like reshape & calls to the BLAS
etc. Real data & imag data are two separate memory chunks,
but each one is contiguous. When freeing this data memory
back to the heap, it would have to be done all at once, not
piecemeal. That would be impossible if other variables were
allowed to share only portions of the data block like
columns. You wouldn't be able to free it until all of the
variables that had pieces were cleared. This would be a
tremendous waste of resources and a nightmare to manage. For
example, do the following:

format debug
a = rand(3,3)
b = a(:,1)
c = a(:,:)
d = a

You can see that the real data pointer pr for b and c are
different from a, indicating that a copy of the data was
made, whereas d and a share the same data pointer. In this
case a copy of the data was made to create c even though it
was the same size and could have used the same data pointer
as a. Now do this:

e = b(:)

Suddenly MATLAB realizes that all of the data is being
copied so an actual copy isn't made ... e simply uses the
same data pointer as b.  I don't know what the rules for
data sharing are, but you can see that it can be tricky to
try and guess what MATLAB will do in every case.

But getting back to OP's original question. Can you modify
input variable data in place and get away with it? The
answer is yes, but only if you are very careful. And even
then you will have to accept some risk. If you create a huge
2GB variable in MATLAB and don't do anything that would
cause data sharing (like the d = a statement above), then
you can get away with modifying the data in place inside a
mex routineand not screw up other variables. The problem, of
course, is that there is no official list (that I am aware
of) of things you  should avoid in order to prevent data
sharing. You should avoid assignments like the d = a above,
of course, but what else?

My advice to OP is to go ahead and do it (at risk) if the
memory/speed penalty is too great otherwise, but never do
MATLAB assignments and function calls that might result in
data sharing with this variable before your mex call.

None of this would be recommended by the Mathworks, of course.

James Tursa