Gary Rubin

Should I read into that statement that forking a queue reference makes a copy of the queue?

I hate when that happens!

I like this idea.

Did the list of Top Reputations on top of the Forums page go away?

Don't know - we have to share time on that system and my time is in the morning. I'll give the queue a try tomorrow AM.

Right. I had that in my head - just forgot to type it.

True, but it's good stuff to know. So, just to beat a dead horse: If I have the reentrant subVI set to Same as Caller, then each instance will be in the thread of the caller and will therefore not require a context switch when called? BTW, just bought the book.

Thanks, Looks like I ought to get a copy of that book. I still don't think that addresses the topic of reentrant vi's, at least not that I saw. I think the crux of my question was whether making a VI reentrant somehow overrides the execution system setting. We're already told to use reentrant VI's when reusing the same VI in two parallel processes. If the answer to the previous question is "no", then do we need to avoid calling reentrant VI's from different threads? Or am I overthinking?

So, that leads me to a question: Do reentrant VI's that are not explicitly set to use the caller's thread involve context switches? Put another way, if a reentrant VI is set to use the caller's thread, does it avoid a context switch? Gary

Thanks Shaun, The LV2 is set at subroutine priority and is therefore same as caller. I see how that would lead to context switching, but what does that actually mean? More overhead associated with calls to the LV2, so each caller spends a little bit more time waiting for it to become available? I can certainly try replacing the LV2 with a queue - that's pretty quick edit. I feel like we tried that a while back, but that was before the existence of VI C. The LV2 is set up as a lossy buffer, with an indicator telling us when it starts to drop data. I'd have to use a lossy queue, with another single element queue to pass the overflow status.

Thanks Ben, I was not aware of the "skip if busy". That's pretty cool. I don't think it would do much in this case though. The producer calls an LV2 in a loop, using a "put" state. The consumer calls the LV2 in a loop, using a "get" state. Normally, the consumer waits on the put state to finish running, and the producer waits on the get state to finish. If I were to use the Skip If Busy in the consumer, it wouldn't wait, but it also wouldn't get any data. Because it hasn't gotten any data, there's nothing for the consumer to do, so the loop iterates again and again, until the LV2 is no longer busy, right? I guess I could see how this could have benefit when using the LV2 for asynchronously passing data into a loop that's busy doing something else that doesn't necessarily require that data every time, but for my case, I don't see it helping. I will try what you suggested, but I'm pretty sure that the input data passing isn't the problem; I still get good behavior if I pass data in but don't process it. Gary

Gurus, I'm hoping someone here has some sage advice. Here's the situation: Running on a Core2 Duo (i.e. dual core processor) VI A dynamically launches VI's B and C. VI B runs in a continuous loop and manages a DMA from a 3rd-party DSP board. It puts a subset of the data into Named Queue 1 and all of the data into a LV2 global. VI A reads the data from the LV2 global, processes it, and puts the results in Named Queue 2 in Loop1. Loop2 flushes Named Queue 2 and transmits the contents via TCP/IP on physical port 1. VI C runs in a continuous loop, flushes Named Queue 1 and transmits the contents via TCP/IP on physical port 2. I am monitoring the intervals between VI C's outputs. Ideally, VI C should be putting out data every 15ms, regardless of what VI A is doing. In order to try to ensure this, I have done the following: All shared VIs are reentrant VIs A, B, and C are all assigned to different Execution Systems VI's B and C are run without opening their front panel. I've observed that when I run things with a typical processing load, the time delta between VI C's outputs gets very noisy, with spikes up in the 100s of ms. I can confirm that the issue is not related to the input traffic by disabling the processing stage of VI A. When I do this, I do see VI C's output every 15ms +/- a couple ms. I see the same thing with the processing enabled if I give it a very small processing load (leading to a very low output load). To me, that points to two possible causes: 1) VI A's processing is monopolizing the system, preventing VI C's loop from running as often as I would like it to. 2) The fact that VI C and VI A are both using TCP/IP writes, although to different ports, is causing some sort of blocking. Slowing down Loop1 in VI A considerably is not an option. Any thoughts? Theoretically, What's going on in VI A should not affect timing of dataflow between VI's B and C, but that's what I'm seeing. Does anyone have any tricks they care to share? Thanks, Gary

I was surprised at how different the runtimes were given that the queue contained a cluster of 4 scalars. I didn't think that copy that would be a very big deal. I guess all things are relative when you're talking about 1e-4 vs. 1e-5 ms.

Trying to do too many things at once... Hova, Shaun is right - my advice was wrong.

Ah, right. I missed constants on the terminations...

You are killing the queue before you have a chance to do the dequeue. The release queue has to be AFTER the dequeue loop.

I just noticed that in LV8.6, a flush of a single-element queue seems to be considerably faster than a preview. Is this expected? Thanks, Gary

Controls (vs. indicators) also have a synchronous/asynchronous setting, but they have to be read with every loop iteration, don't they? Or do they work the same way as asynchronous indicators, where the code will "catch" a change in asynchronous control status whenever it gets around to it? I'm trying to figure out if my processing loop that contains a bunch of controls would run more efficiently if I moved those controls out to a slower loop and passed the results into the processing loop using queues.

I noticed something similar in 8.6. I think it beeps when I go from Run mode to Edit mode for a reentrant VI (the ones that say "clone" in the title bar). Might that be what you're seeing (er... hearing)?

Looks like a scene out of The Mummy

That's great! Thanks for the laugh!

The code in question performs a running median. Because the length of my window is 4, I've removed the Sort by calculating the median as (sum(Array)-max(Array)-min(Array))/2. It already runs very fast (~3.8us), but considering how often it runs, that adds up to a majority of my processing time. I could maybe add some bookkeeping to not have find Max and Min each time, but I'm not sure how much that would help, given my short window size. I guess the first thing to do is code up the slowest part in C and see how it compares to LV, then worry about transitioning the whole thing, if necessary.

Thanks. That's nice to hear, as I know how to call a dll, but have never done a CIN.

I seem to recall that NI used to recommend writing really time-critical subroutines in C, then calling from LabVIEW. Is that still recommended (for LV8.6)? If so, is it better to call as a DLL or a CIN? Thanks, Gary