Thread Subject:

Peter Boettcher's mxArray Tag for 64-bit

Does anybody have any experience (Bruno?) using the mxArray tag stuff for 64-bit MATLAB? I need to get direct access to the pr and pi pointer so I can create some temporary mxArrays using "non-approved" memory locations. I can't use the mxSetPr function because it throws an assertion error when this is done for newer versions of MATLAB. I have the 32-bit version of my code working but I do not have a 64-bit system to test with. Any help on getting a working mxArray structure for 64-bit would be appreciated. Eventually this will go into an FEX submission and I don't want to break the code for 64-bit machines. Thanks.

James Tursa

"James Tursa" <aclassyguy_with_a_k_not_a_c@hotmail.com> wrote in message <i92vpn$na4$1@fred.mathworks.com>...
> Does anybody have any experience (Bruno?) using the mxArray tag stuff for 64-bit MATLAB? I need to get direct access to the pr and pi pointer so I can create some temporary mxArrays using "non-approved" memory locations. I can't use the mxSetPr function because it throws an assertion error when this is done for newer versions of MATLAB. I have the 32-bit version of my code working but I do not have a 64-bit system to test with. Any help on getting a working mxArray structure for 64-bit would be appreciated. Eventually this will go into an FEX submission and I don't want to break the code for 64-bit machines. Thanks.
>
> James Tursa

Hi James,

yes, I have done that. In my submission InplaceArray on FEX, it works for both 32/64 bits up to 2010A. It build the internal mxArray header by hacking 'matrix.h' file.

Just a week ago, I take a look at maArray TAG on 2010B, but it seems the TAG is hidden by TMW, however the internal structure seems to be unchanged from 2010A. I need to work out to see how to hack it.

Here is the mxArray TAG currently built with 2010A 64 bit (but stilll work for 2010B):

 /* Built automatically by buildInternal_mxArrayDef.m
Built date: 29-Jun-2009 12:31:52
Matlab version: 2009a
*/

typedef struct {
    void *reserved;
    int reserved1[2];
    void *reserved2;
    size_t number_of_dims;
    unsigned int reserved3;
    struct {
        unsigned int flag0 : 1;
        unsigned int flag1 : 1;
        unsigned int flag2 : 1;
        unsigned int flag3 : 1;
        unsigned int flag4 : 1;
        unsigned int flag5 : 1;
        unsigned int flag6 : 1;
        unsigned int flag7 : 1;
        unsigned int flag7a: 1;
        unsigned int flag8 : 1;
        unsigned int flag9 : 1;
        unsigned int flag10 : 1;
        unsigned int flag11 : 4;
        unsigned int flag12 : 8;
        unsigned int flag13 : 8;
    } flags;
    size_t reserved4[2];
    union {
        struct {
            void *pdata;
            void *pimag_data;
            void *reserved5;
            size_t reserved6[3];
        } number_array;
    } data;
} Internal_mxArray;

Bruno

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <i931nj$qrh$1@fred.mathworks.com>...
> "James Tursa" <aclassyguy_with_a_k_not_a_c@hotmail.com> wrote in message <i92vpn$na4$1@fred.mathworks.com>...
> > Does anybody have any experience (Bruno?) using the mxArray tag stuff for 64-bit MATLAB? I need to get direct access to the pr and pi pointer so I can create some temporary mxArrays using "non-approved" memory locations. I can't use the mxSetPr function because it throws an assertion error when this is done for newer versions of MATLAB. I have the 32-bit version of my code working but I do not have a 64-bit system to test with. Any help on getting a working mxArray structure for 64-bit would be appreciated. Eventually this will go into an FEX submission and I don't want to break the code for 64-bit machines. Thanks.
> >
> > James Tursa
>
> Hi James,
>
> yes, I have done that. In my submission InplaceArray on FEX, it works for both 32/64 bits up to 2010A. It build the internal mxArray header by hacking 'matrix.h' file.
>
> Just a week ago, I take a look at maArray TAG on 2010B, but it seems the TAG is hidden by TMW, however the internal structure seems to be unchanged from 2010A. I need to work out to see how to hack it.
>
> Here is the mxArray TAG currently built with 2010A 64 bit (but stilll work for 2010B):
>
     (snip)

Thanks, Bruno.

James Tursa

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <i931nj$qrh$1@fred.mathworks.com>...
>
> Here is the mxArray TAG currently built with 2010A 64 bit (but stilll work for 2010B):
>
> /* Built automatically by buildInternal_mxArrayDef.m
> Built date: 29-Jun-2009 12:31:52
> Matlab version: 2009a
> */
>
> typedef struct {
> void *reserved;
> int reserved1[2];
> void *reserved2;
> size_t number_of_dims;

(snip)

Follow up question. What are the values of the following on your 64-bit setup:

sizeof(void *)
sizeof(short)
sizeof(int)
sizeof(long)
sizeof(long long)
sizeof(size_t)
sizeof(ptrdiff_t)
sizeof(mwSize)

Thanks.

James Tursa

Compile with -largeArrayDims
sizeof(void *)=8
sizeof(short)=2
sizeof(int)=4
sizeof(long)=4
sizeof(long long)=8
sizeof(size_t)=8
sizeof(ptrdiff_t)=8
sizeof(mwSize)=8
************************************************
Compile WITHOUT -largeArrayDims
sizeof(void *)=8
sizeof(short)=2
sizeof(int)=4
sizeof(long)=4
sizeof(long long)=8
sizeof(size_t)=8
sizeof(ptrdiff_t)=8
sizeof(mwSize)=4

Bruno

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <i951bv$hvt$1@fred.mathworks.com>...
> Compile with -largeArrayDims
> sizeof(void *)=8
> sizeof(short)=2
> sizeof(int)=4
> sizeof(long)=4
> sizeof(long long)=8
> sizeof(size_t)=8
> sizeof(ptrdiff_t)=8
> sizeof(mwSize)=8
> ************************************************
> Compile WITHOUT -largeArrayDims
> sizeof(void *)=8
> sizeof(short)=2
> sizeof(int)=4
> sizeof(long)=4
> sizeof(long long)=8
> sizeof(size_t)=8
> sizeof(ptrdiff_t)=8
> sizeof(mwSize)=4
>
> Bruno

Thanks again.

James Tursa

Dear Bruno,

> Compile with -largeArrayDims
> sizeof(mwSize)=8
> Compile WITHOUT -largeArrayDims
> sizeof(mwSize)=4

Which Matlab? I expect this for 2010b:

> Compile WITHOUT -compatibleArrayDims and WITHOUT -largArrayDims
> sizeof(mwSize)=8
> Compile WITH -compatibleArrayDims
> sizeof(mwSize)=4

And which compiler? I expected INT to use 64 bits in a 64 bit setup.

Kind regards and thanks, Jan

"Jan Simon" <matlab.THIS_YEAR@nMINUSsimon.de> wrote in message <i959vf$h6p$1@fred.mathworks.com>...
>
> And which compiler? I expected INT to use 64 bits in a 64 bit setup.

Although I don't have a 64-bit setup, that has not been my impression from other posts. For at least some other 64-bit systems, int has been 32-bits and long has sometimes been 32-bits and sometimes 64-bits. If anyone out there has a 64-bit system where the default int (without setting special compiler flags) is 64-bit I would like to hear about it.

As an aside, a similar situation seems to apply to Fortran. The default INTEGER size in Fortran on some 64-bit systems is a 32-bit integer, not 64-bit integer.

My guess is this is a choice of the compiler vendors to try and give the code the best chance to compile and run correctly in case there are hidden assumptions on the part of the programmer about the size of an int or INTEGER being 32-bits.

James Tursa

"James Tursa" <aclassyguy_with_a_k_not_a_c@hotmail.com> wrote in message <i95ee0$3cf$1@fred.mathworks.com>...
> "Jan Simon" <matlab.THIS_YEAR@nMINUSsimon.de> wrote in message <i959vf$h6p$1@fred.mathworks.com>...
> >
> > And which compiler? I expected INT to use 64 bits in a 64 bit setup.
>
> Although I don't have a 64-bit setup, that has not been my impression from other posts. For at least some other 64-bit systems, int has been 32-bits and long has sometimes been 32-bits and sometimes 64-bits. If anyone out there has a 64-bit system where the default int (without setting special compiler flags) is 64-bit I would like to hear about it.
>
> As an aside, a similar situation seems to apply to Fortran. The default INTEGER size in Fortran on some 64-bit systems is a 32-bit integer, not 64-bit integer.
>
> My guess is this is a choice of the compiler vendors to try and give the code the best chance to compile and run correctly in case there are hidden assumptions on the part of the programmer about the size of an int or INTEGER being 32-bits.

My observation is in agreement with James's, though I'm only exposed to MSVC and gcc for 64 bit system. I use Intel C and LCC but exclusive to 32-bit system.
 
@Jan, yes I have 2010B setup as I wrote in post #2.

Bruno

> @Jan, yes I have 2010B setup as I wrote in post #2.

Thanks, Bruno! Obviously there are too many cookie crumbles on my screen after testing some algorithms. Jan

James Tursa <aclassyguy_with_a_k_not_a_c@hotmail.com> wrote:
> "Jan Simon" <matlab.THIS_YEAR@nMINUSsimon.de> wrote in message <i959vf$h6p$1@fred.mathworks.com>...
>>
>> And which compiler? I expected INT to use 64 bits in a 64 bit setup.

Not on any systems I have used. Int seems most often to be 4 bytes, but
the standards do leave this up to the compiler vendor.

>
> Although I don't have a 64-bit setup, that has not been my impression
> from other posts. For at least some other 64-bit systems, int has been
> 32-bits and long has sometimes been 32-bits and sometimes 64-bits. If
> anyone out there has a 64-bit system where the default int (without setting
> special compiler flags) is 64-bit I would like to hear about it.
>

On solaris x86 or Sparc, I see int is 4, long is 4 or 8, and long long is 8.
If it makes a difference to your code, then always be certain to check.

cow 133% uname -a
SunOS cow 5.10 Generic_142910-17 i86pc i386 i86pc
cow 134% cat hello.c
#include <stdio.h>

int main(int argc, char *argv[])
{
    printf("Hello world\n");
    printf("Sizeof int is %d\n", sizeof(int));
    printf("Sizeof long is %d\n", sizeof(long));
    printf("Sizeof long long is %d\n", sizeof(long long));
}
cow 135% cc -o hello32 hello.c
cow 136% cc -o hello64 -m64 hello.c
cow 137% file hello[0-9]?
hello32: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically
linked, not stripped
hello64: ELF 64-bit LSB executable AMD64 Version 1 [SSE FXSR FPU],
dynamically linked, not stripped
cow 138% ./hello32
Hello world
Sizeof int is 4
Sizeof long is 4
Sizeof long long is 8
cow 139% ./hello64
Hello world
Sizeof int is 4
Sizeof long is 8
Sizeof long long is 8
cow 140%



[snip]

>
> James Tursa

--
Dr Tristram J. Scott
Energy Consultant

It looks to me like Mathworks has removed array access inlining for Matlab r2010b. I no longer see the definition for struct mxArray_tag in matrix.h. Can someone confirm this? Also, in the future if Mathworks modifies the struct definition (from say r2010a where I last saw it), we will have more trouble reverse engineering the mxArray type. Naturally this is precisely why they have done this.

Cheers,

Josh

"Joshua Dillon" <foo@bar.com> wrote in message <ienn5s$sn3$1@fred.mathworks.com>...
> It looks to me like Mathworks has removed array access inlining for Matlab r2010b. I no longer see the definition for struct mxArray_tag in matrix.h. Can someone confirm this? Also, in the future if Mathworks modifies the struct definition (from say r2010a where I last saw it), we will have more trouble reverse engineering the mxArray type. Naturally this is precisely why they have done this.
>

Yes, I confirm the mxArray Tag can be no longer seen since 2010B. I hope the real reason is not to prevent the amateurish reverse engineering the minority of us did here, this would be pity.

Bruno

"James Tursa" wrote in message <i92vpn$na4$1@fred.mathworks.com>...
> Does anybody have any experience (Bruno?) using the mxArray tag stuff for 64-bit MATLAB? I need to get direct access to the pr and pi pointer so I can create some temporary mxArrays using "non-approved" memory locations. I can't use the mxSetPr function because it throws an assertion error when this is done for newer versions of MATLAB. I have the 32-bit version of my code working but I do not have a 64-bit system to test with. Any help on getting a working mxArray structure for 64-bit would be appreciated. Eventually this will go into an FEX submission and I don't want to break the code for 64-bit machines. Thanks.
>
> James Tursa

Hi James, I was wondering if the "non-approved" memory locations were created by the MATLAB process and if you use Windows? I tried using this approach to access shared memory (hacking the sharedmatrix FEX submission to use BOOST so it works on Windows) , but the call :

(*mxInput))->data.number_array.pdata = pBuffer;

crashes MATLAB (R2010A) immediately, even from the process that created the shared mem. pBuffer is definately valid and I can copy its data into mx allocated space (from other processes as well). It also works when pBuffer points to a static (non shared non mx allocated) buffer created in a mex file. I was thinking it might have something to do with which process the memory belongs to, and the global memory not belonging to the MATLAB process.

Also I was wondering if anyone tried using the "reference count" for mxArrays with data in "non-approved" memory locations? If there was some reverse of mxUnreference it might become safe to let MATLAB clear these variables.

Cheers,
Andrew

"Andrew" wrote in message <ij2a0s$670$1@fred.mathworks.com>...
> "James Tursa" wrote in message <i92vpn$na4$1@fred.mathworks.com>...
> > Does anybody have any experience (Bruno?) using the mxArray tag stuff for 64-bit MATLAB? I need to get direct access to the pr and pi pointer so I can create some temporary mxArrays using "non-approved" memory locations. I can't use the mxSetPr function because it throws an assertion error when this is done for newer versions of MATLAB. I have the 32-bit version of my code working but I do not have a 64-bit system to test with. Any help on getting a working mxArray structure for 64-bit would be appreciated. Eventually this will go into an FEX submission and I don't want to break the code for 64-bit machines. Thanks.
> >
> > James Tursa
>
> Hi James, I was wondering if the "non-approved" memory locations were created by the MATLAB process and if you use Windows?

Yes and Yes.

> I tried using this approach to access shared memory (hacking the sharedmatrix FEX submission to use BOOST so it works on Windows) , but the call :
>
> (*mxInput))->data.number_array.pdata = pBuffer;
>
> crashes MATLAB (R2010A) immediately, even from the process that created the shared mem.

You will probably have to share more information on this line before I can comment on it. Assuming that you have all the pointers set up correctly, I can see no reason why this would crash MATLAB since nothing has yet tried to access pBuffer. So I would have to assume that something is wrong with mxInput. But this is just a guess. I would seriously doubt that there is a different structure used for Windows vs other OS's, as the same header file seems to be set up for both.

> pBuffer is definately valid and I can copy its data into mx allocated space (from other processes as well). It also works when pBuffer points to a static (non shared non mx allocated) buffer created in a mex file. I was thinking it might have something to do with which process the memory belongs to, and the global memory not belonging to the MATLAB process.

Mixing non-mx allocated memory into mxArrays will likely crash MATLAB at some point unless you are very careful and know what you are doing. When MATLAB tries to destroy this array it will try to free memory that does not belong to it, hence the problems. You would need to manually detach the pointers and NULL them out before destroying the mxArray in order to avoid this, and be sure you didn't do anything to cause a shared-data-copy to be hanging around off to the side somewhere.

Mixing memory from a different process altogether is another matter, and it would not surprise me that this would cause problems. What, exactly, are you attempting to do? Where does this pBuffer value come from? Why is it a different process from MATLAB?

> Also I was wondering if anyone tried using the "reference count" for mxArrays with data in "non-approved" memory locations? If there was some reverse of mxUnreference it might become safe to let MATLAB clear these variables.

The reference count is for subelements like fields and cells. It is not, to my knowledge, used for ordinary variables. e.g., if you do this at the MATLAB command line:

A = rand(1,3);
B = A;

Then B will be a shared data copy of A. This means that B has its own mxArray structure but the pr and pi pointers (your pdata) are the same as A. On the other hand, suppose you do this:

A = rand(1,3);
B = {A ,A, A};

In that case the cell elements of B will be reference copies of A, not shared data copies. i.e., the cell elements of B share *everything* with A, including the mxArray header stuff. Unless you are building a structure or cell array in your mex routine you would not use the reference count to create a sharing condition.

Unreferencing a variable is easy to do, btw. You just decrement the reference count field of the mxArray structure and then NULL out the cell or field element pointer in question.

James Tursa

 > > -- snip -- James wrote:
 > > You will probably have to share more information on this line before I can comment on it. Assuming that you have all the pointers set up correctly, I can see no reason why this would crash MATLAB since nothing has yet tried to access pBuffer. So I would have to assume that something is wrong with mxInput. But this is just a guess. I would seriously doubt that there is a different structure used for Windows vs other OS's, as the same header file seems to be set up for both.

Thanks James. I had another look through my code and discovered I was inadvertantly destoying my file mapping to the shared memory on mex exit, which explains why the data pointer was invalid and Matlab crashed.

The goal of this is to place Matlab data in shared memory, so when I use the parellel toolbox on a single machine with multiple cores, I don't have to copy large variables to each spawned Matlab process's memory space. Its for a Windows version of Joshua Dillon's sharedmatrix submission on FEX.
 
> > - snip -
> Andrew wrote:
> Also I was wondering if anyone tried using the "reference count" for mxArrays with data in "non-approved" memory locations? If there was some reverse of mxUnreference it might become safe to let MATLAB clear these variables.
>
> James wrote: The reference count is for subelements like fields and cells. It is not, to my knowledge, used for ordinary variables. e.g., if you do this at the MATLAB command line:
>
> A = rand(1,3);
> B = A;
>
> Then B will be a shared data copy of A. This means that B has its own mxArray structure but the pr and pi pointers (your pdata) are the same as A. On the other hand, suppose you do this:
>
> A = rand(1,3);
> B = {A ,A, A};
>
> In that case the cell elements of B will be reference copies of A, not shared data copies. i.e., the cell elements of B share *everything* with A, including the mxArray header stuff. Unless you are building a structure or cell array in your mex routine you would not use the reference count to create a sharing condition.
>
> Unreferencing a variable is easy to do, btw. You just decrement the reference count field of the mxArray structure and then NULL out the cell or field element pointer in question.
>
> James Tursa

I had some luck with the reference counts for mxArrays with data in non-approved locations. I was playing with Bruno's inplacearray Fex submission, and I found that by manually setting reserved3 = 1 (using the mxArray definition in this thread) Matlab stops trying to free the data pointer when the variable is cleared, making it "safe" for Matlab to clear the variable.

Thanks again,
Andrew

"Andrew" wrote in message <ija0h0$484$1@fred.mathworks.com>...
>
> I had some luck with the reference counts for mxArrays with data in non-approved locations. I was playing with Bruno's inplacearray Fex submission, and I found that by manually setting reserved3 = 1 (using the mxArray definition in this thread) Matlab stops trying to free the data pointer when the variable is cleared, making it "safe" for Matlab to clear the variable.

MATLAB does not free *anything* when a reference copy is cleared. The only thing it does is decrement the reference count number by one. Remember, if the reference count is non-zero then MATLAB thinks that the entire variable, including all of the mxArray header stuff, is shared by another cell or field variable. So MATLAB will not actually attempt to free *anything* associated with the variable in this case, including the header stuff, the data areas, etc. Be aware that this is a counter, not a flag. If you set the reference count = 1 and then let MATLAB try to clear the variable twice then on the 2nd attempt the reference count will be 0 and MATLAB *will* try to free everything.

James Tursa

"James Tursa" wrote in message <ija5gb$lg5$1@fred.mathworks.com>...
> "Andrew" wrote in message <ija0h0$484$1@fred.mathworks.com>...
> >
> > I had some luck with the reference counts for mxArrays with data in non-approved locations. I was playing with Bruno's inplacearray Fex submission, and I found that by manually setting reserved3 = 1 (using the mxArray definition in this thread) Matlab stops trying to free the data pointer when the variable is cleared, making it "safe" for Matlab to clear the variable.
>
> MATLAB does not free *anything* when a reference copy is cleared. The only thing it does is decrement the reference count number by one. Remember, if the reference count is non-zero then MATLAB thinks that the entire variable, including all of the mxArray header stuff, is shared by another cell or field variable. So MATLAB will not actually attempt to free *anything* associated with the variable in this case, including the header stuff, the data areas, etc. Be aware that this is a counter, not a flag. If you set the reference count = 1 and then let MATLAB try to clear the variable twice then on the 2nd attempt the reference count will be 0 and MATLAB *will* try to free everything.
>
> James Tursa

What is the meaning of reserved3? The total number of variables that share the data?

It does not seem to be justified to set it to 1, it's a safe guard to user to use CLEAR wrongly (once as James explains), but calling CLEAR is still wrong. I rather en let it as it is, so as user use REPLEASEINPLACE, more appropriate than CLEAR. Do you agree Andrew and James?

Bruno

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <ijaiqq$6l5$1@fred.mathworks.com>...
>
> What is the meaning of reserved3? The total number of variables that share the data?

Yes and No. reserved3 is the total number of variables that are "reference copies" of this variable present in the entire MATLAB program. So in essence they share both data *and* header. This is different from a shared data copy, where a linked list is created to map out all of the shared variables, each with the same pr and pi but having different headers. A variable can be both. i.e., a variable can have multiple references to it present in cell arrays and structures and *also* have shared data copies of it in other variables at the same time.

> It does not seem to be justified to set it to 1, it's a safe guard to user to use CLEAR wrongly (once as James explains), but calling CLEAR is still wrong. I rather en let it as it is, so as user use REPLEASEINPLACE, more appropriate than CLEAR. Do you agree Andrew and James?

It all depends on exactly what is being done and how many copies MATLAB itself has access to. e.g., if you create a variable in a mex routine, set reserved3=1, and then return this back to MATLAB via plhs, then I *think* (I haven't tried this yet) the variable will end up existing in the workspace with reserved3=1. So you have faked out MATLAB into thinking that there is a cell array or structure around somewhere that has this exact variable as one of the elements, even though there isn't any such association actually present. When you issue a CLEAR command on this variable, MATLAB will look at reserved3, see that it is non-zero, decrement reserved3 by 1, delete the name of the variable from it's workspace list, and that's it. It will *not* try to actually free the header or data areas associated with this variable since it thinks there is another reference to it somewhere else in the
program.

If you are using this variable in some other manner than returning it via plhs then I would have to ask for the details before offering an opinion.

James Tursa

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <ijaiqq$6l5$1@fred.mathworks.com>...
> "James Tursa" wrote in message <ija5gb$lg5$1@fred.mathworks.com>...
> > "Andrew" wrote in message <ija0h0$484$1@fred.mathworks.com>...
> > >
> > > I had some luck with the reference counts for mxArrays with data in non-approved locations. I was playing with Bruno's inplacearray Fex submission, and I found that by manually setting reserved3 = 1 (using the mxArray definition in this thread) Matlab stops trying to free the data pointer when the variable is cleared, making it "safe" for Matlab to clear the variable.
> >
> > MATLAB does not free *anything* when a reference copy is cleared. The only thing it does is decrement the reference count number by one. Remember, if the reference count is non-zero then MATLAB thinks that the entire variable, including all of the mxArray header stuff, is shared by another cell or field variable. So MATLAB will not actually attempt to free *anything* associated with the variable in this case, including the header stuff, the data areas, etc. Be aware that this is a counter, not a flag. If you set the reference count = 1 and then let MATLAB try to clear the variable twice then on the 2nd attempt the reference count will be 0 and MATLAB *will* try to free everything.
> >
> > James Tursa
>
> What is the meaning of reserved3? The total number of variables that share the data?
>
> It does not seem to be justified to set it to 1, it's a safe guard to user to use CLEAR wrongly (once as James explains), but calling CLEAR is still wrong. I rather en let it as it is, so as user use REPLEASEINPLACE, more appropriate than CLEAR. Do you agree Andrew and James?
>
> Bruno

Hi Bruno,

James and yourself are right so my apologies (anyone know how to delete a comment on Fex?). I was incorrectly trying to use refcount instead of the crosslink. The crosslink approach worked in terms of clearing BMAT as long as you clear it before AMAT, but sadly Matlab's garbage collector doesn't destroy variables in the reverse order to which they were created (as per my understanding of objects in C++). I'll be quiet now.

Andrew

"Andrew" wrote in message <ijbo0k$hsu$1@fred.mathworks.com>...
> I'll be quiet now.

Ah don't, I appreciate very much such input.

Bruno

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <ijbon4$3pi$1@fred.mathworks.com>...
> "Andrew" wrote in message <ijbo0k$hsu$1@fred.mathworks.com>...
> > I'll be quiet now.
>
> Ah don't, I appreciate very much such input.
>
> Bruno

Ditto. Please don't be quiet. We are all in the same boat trying to learn this stuff to push MATLAB capabilities and efficiencies to the extreme. I did not mean to imply by my comments that setting reserved3=1 when you weren't really using a cell or struct was necessarily a bad thing to do. If you have to do something like that to get things to work then by all means do it (and share your results!). But it *is* important to understand how MATLAB will deal with such a variable if it ever gets back to the MATLAB workspace or you pass it off to another function via mexCallMATLAB or whatever. If you understand the consequences and can deal with them appropriately then you will be OK. e.g., in my previous post I described the situation where you could fake out MATLAB into thinking that there was another reference copy of a variable around in the workspace somewhere when in fact there wasn't.
That would be a memory leak problem unless you, as the programmer, dealt with it. e.g., you would have to keep track of the mxArray address separately inside your mex function and then register a mexAtExit function to clean this up in case the mex function itself is cleared. Or maybe some other scheme of keeping track of it off to the side will work better. etc. etc. So the burden of keeping all the memory intact and not corrupted and not leaking falls on you the programmer in these cases. But sometimes you just have to do it to avoid the huge penalties of memory use and/or timing if you stick with the MATLAB official API functions.

James Tursa

Just to add my two cents (so I don't feel left out from this little mxArray club)...

For purposes of my sharedmatrix code, I didn't find reserved3 to be helpful since I don't want the copy-on-write mechanism to kick-in as it would for both non-hacked mxArray references as well as reserved3 hacked. Still though, I wanted to protect against clear.

My only other idea was based on wrapping the sharedmatrix variable reference into a "persistent" variable. Unfortunately I never got this to work as I wanted, but perhaps one of you may have a cute way to do this or it will inspire some better idea.

Cheers,

Josh

http://www.mathworks.com/help/techdoc/ref/persistent.html