How about simply putting a flag on the Obtain Q? This would prevent the user from needing to do a flattened-data-size-times-number-of-elements calculation. But I have to ask, in what situation would this function be most helpful?
I thought about a switch on the Obtain Queue - even had it typed into my idea. But, I erased it because that function is so classic, I personally would not want it modified for something that would be technically a bit esoteric to a beginner. I fuss over those switches all the time, such as Force Destroy, etc, and I think this feature should not be fussed over when doing something very basic - it should be it's own function, with it's own Help, etc. Just my 2c.
Like the idea, more with with JackDunaway twist. Just put this extra flag as a optional terminal and make it back compatible with the old Obtain Queue. No connection, no preallocation, just like now. Don't like the idea of creating a new VI just to preallocate, this is something intrinsic to the queue creation.
I like the Idea, but it's a small step toward bucking the trend of LabVIEW managed memory - the see-saw between "LabVIEW is easy" and "LabVIEW is powerful". I would like to hear some discussion on how this functionality is better suited to accomplish tasks than what is possible with the current implementation.
Message Edited by JackDunaway on 04-08-2010 11:58 AM
> how this functionality is better suited
to accomplish tasks than
> what is possible with the current
implementation.
For those who dont't know, the "current implementation" of which Jack speaks is right after you do the Obtain Queue you do a For Loop and call Enqueue N times and then Flush the queue ... now the queue has space reserved for N items... a useful trick on RT systems.
As for "separate prim" vs "part of Obtain":
Advantage for "separate prim": There can be multiple calls to obtain the same named reference. We already have a strange case today where the first call to Obtain for the same name pass in different queue sizes. If we add this new terminal, we have a similar issue to define the behavior when the first Obtain had one setting and the second Obtain had a different setting. It's not an error case like the max size terminal, but it is functionality that would have to be defined and would add to the erratta of this node's behavior.
Advantage for "part of Obtain": Small performance gain from not having to generate the refnum and then turn right back around and look up the reference again. Also there wouldn't be a hole in the atomic operations (not sure if that's important or not, but it is an advantage of the Obtain solution).
Well, this idea has gathered a little more dust than I would have hoped. It seems like an easy and obvious performance gain, even if it's almost academic on a non-RT target. LabVIEW has placed several new tidbits to perform some of our own memory management (to some degree) such as Always Copy, Request Deallocation, etc. Something like this seems to fit that bill. Maybe put this function in the memory control palette?
