Memory Management, Preserve memory buffer

[JÞB]

This post

Has gotten me thinking about how to handle preserving a memory location for external data updates.  @009 has much better memory management- couldn't a Preserve Memory primitive be written? For obvious reasons a counterpart Deallocate would need to be required for each "Preserve" call

[RavensFan]

I haven't heard of @009 before.

But isn't what you are looking for basically comparable to the new Data Value Reference functions in LabVIEW 2009?

Message Edited by Ravens Fan on 10-28-2009 10:08 PM

[Intaris]

@009 is obviously supposed to be 2009.....  I don't know where the @ is -at- (pun intended) on US keyboards but in Europe it co-habitis the "2" key.

@Jeff : Is this meant to be in conjunction with DLL calls?  How does an external routine gain access to the reserved memory?

Shane.

[JÞB]

Yes <shift-2> is where its @.  I tend to get a bit confused with the shift and caps-lock keys (very embaressing) but blame it on LabVIEW.  Also- I'm a tabber- (the tool selector has some disadvantages) and a BAD typist-  I put lots of "``" comments in my code when I miss the TAB.

@Intaris-  The post linked does have code with a dll call.  Pass in a buffer and it continues to update that memory location.  Some surprising effects occur!  What exactly can be done to make this type of dll fn safe in LabVIEW?  This idea is simply to prevent LabVIEW's dynamic memory manager from re-assigning a block of memory that is updated from outside LabVIEW

[tst]

> What exactly can be done to make this type of dll fn safe in LabVIEW? 

Don't create the buffer in LabVIEW. Use a function in the DLL to allocate the memory and return a pointer to it.

Or do you expect to have a single copy which will be shared between the LV code and the DLL code?

[tst]

> What exactly can be done to make this type of dll fn safe in LabVIEW? 

Don't create the buffer in LabVIEW. Use a function in the DLL to allocate the memory and return a pointer to it.

Or do you expect to have a single copy which will be shared between the LV code and the DLL code?

[RavensFan]

@009.  2009.  Of course that makes sense now.   It just didn't cross my mind when I read it.  And there have been several recent posts on the forums lately where people have been referring to programs I've never heard of before  (someone was recently asking about "vbx spreadsheet").  I just thought this was another one of those arcane programs.

For reference, this idea seems to be related to this message thread.

http://forums.ni.com/ni/board/message?board.id=170&thread.id=451133&view=by_date_ascending

Message Edited by Ravens Fan on 10-29-2009 09:56 AM

[Intaris]

@Jeff,

Somehow my brain had filtered out the Hyperlink.  I had been reading the thread on the support forum so I kind of guessed that was the kind of thing being referenced (no pun intended).

Interesting idea.  Maybe someone from NI could tell us something which prevents a memory re-map which could essentially give you the functionality you are looking for?

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.