LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
JÞB

Memory Management, Preserve memory buffer

Status: Declined

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

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

 

hmm2.PNG


"Should be" isn't "Is" -Jay
8 Comments
RavensFan
Knight of NI

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
Proven Zealot

@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
Knight of NI

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


"Should be" isn't "Is" -Jay
tst
Knight of NI Knight of NI
Knight of NI

> 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?


___________________
Try to take over the world!
tst
Knight of NI Knight of NI
Knight of NI

> 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?


___________________
Try to take over the world!
RavensFan
Knight of NI

@009.  2009.  Of course that makes sense now. Smiley Very Happy  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
Proven Zealot

@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
Proven Zealot
Status changed to: Declined

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