01-29-2007 09:51 AM
For large number of items, the performance difference is really big. Also wait for notification or wait for multiple notifications nodes cannot be used in a non-re-entrant subVI safely as is described in this thread. So to use notifiers safely, you would still need to do the dynamic VI call trick and the performance would be even worse. The only build-in mechanism that is safe for synchronization purposes is single element queues.
Perhaps I'm just being a bit thick (hey, it's Monday), but what's the advantage of this over an array of boolean notifiers? There's a slight performance advantage of occurrences, I understand, but don't you use that up by the dynamic VI Server calls? In this example, you could even use a U32 notifier, and combine the synchronization of the notifier with sending the data to the other VI.
01-29-2007 10:00 AM
01-29-2007 10:21 AM - edited 01-29-2007 10:21 AM
Jarrod,
Tomi's code closes the reference to the re-entrant sub-VI call and in so doing the occurrences associated with that instance of the VI are destroyed.
The code works OK if we jut delete the "close" but then we have to concern ouselves with pssoible memory leaks.
Ben
Message Edited by Ben on 01-29-2007 10:22 AM
01-29-2007 11:01 AM
Ben, I try to figure out a good fix to the issue.Tomi's code closes the reference to the re-entrant sub-VI call and in so doing the occurrences associated with that instance of the VI are destroyed.
01-29-2007 01:35 PM
This is pretty cool, but was I the only one a little confused by the explicit use of the term "non-re-entrant" in Ben's original post? I'm pretty sure every time you said "non-re-entrant" you really meant that it WAS reentrant.
Also, not sure how the 0x08 flag to Open VI Reference might affect things. I was a little surprised to see your screenshots not using it, but perhaps it's not required in that use case.
In any case, thanks for the nugget Ben!
01-29-2007 03:51 PM - edited 01-29-2007 03:51 PM
@Tomi M wrote:For large number of items, the performance difference is really big. Also wait for notification or wait for multiple notifications nodes cannot be used in a non-re-entrant subVI safely as is described in this thread. So to use notifiers safely, you would still need to do the dynamic VI call trick and the performance would be even worse. The only build-in mechanism that is safe for synchronization purposes is single element queues.
Message Edited by eaolson on 01-29-2007 03:52 PM
01-29-2007 04:24 PM
OK, a lot of good points have been made.
Tomi,
If you turned your Get Multiple.... into an action engine that cached the Occurrences and the VI used to create it in an INIT case
and
Accepted the occurrence in another state "close" then a search 1-d array on the occurence would give you the index of the VI that created that Occurrence.
Jeff,
The "08" flag is not required when opening a VI that is marked as "Entrant" ( is that the correct term for a VI where it is NOT re-entrant?). I seem to rember being able to use that switch to open re-entrant VI's as "Entrant" but I only have LV 7.1 and above on my laptop and can not test older versions.
Eolson,
Yes I could have used a notifier. I had concidered doing that but that method did not present as many challenges. By presenting this as a OBA, it gets us talking about Entrant vs Re-entrant, VI resource allocation etc. Ifmy memory serves me, the Occurrence take less CPU. On the other hand, if I wanted to specify the intesity of the note or some other quality that goes with the sounding of the note, the Notify would probably help out.
Again thank you all for reading!
Ben
01-29-2007 06:45 PM
Tomi,
Your re-cursive approach will complicate closing blocks of Occurrences. A re-iterative approach would work,.... close a VI when its block of Ocuurrences have all asked to be closed. This would take twice as much code as I put into the original Nugget!
Ben
01-30-2007 02:29 AM
01-30-2007 07:36 AM
I will probably not have enough free time this week to develop the occurrence Create/Destroy function so I may save this for another nugget.
This is how I imagine it working.
On 1st call
Clear array of Occurrnces -This array will cache all created occurnces. As you started, they will be created in batches of 32. A new batch will be created any time the caller asks for more than are in this array.
Clear array of "Available" boolean flags - AS the available Occurnences are passed to callers they will be marked as "un-available".
Clear array of "Pending Close" flags - When a references is requested to be closed, they coresponding boolean will be set. Any time a "set of 32" have all asked to be closed, the ref to the VI that created that batch can be closed.
Clear array of VI refences - This array will store the VI refs so we can close them when all of the created Occurrences from that VI have been requested to be closed.
Get Occurences -Action
Check if there enough "free Occurnces" to satisfy request. If so return the free Occurrences and mark them as "un-available".
If not enough are available, create enough allog with "Available" and "Marked for Close" and cache the Occurneces and the VI ref.
Occurrence Close -Action
Look up Occurnec in list and mark as "Marked for close". If after a btach of 32 are all marked for close, then close the VI ref.
Note:
When requested to close, the Occurnce should be marked as available to allow for the Occfurnces to be re-sued by another process.
That is just the general outline of an approach I think will work.
Like I said, maybe a future nugget?
Ben