Rather Long Execution Time for Release Queue.vi

[Oli_Wachno]

Hi,

I'm trying to understand a (at least for me) weird behaviour with the execution time of the Release Queue.vi.

First fo all, this is what I'm doing:

In my application, I'm using queues to communicate with two asynchronous VI clones. They are started using Open VI Reference.vi (Option 0xC0). One of the asynchronous VIs Input terminal is a queue reference. A seperate queue is created for each clone in the TopLevel VI and passed when invoking the asynchronous VI.

Starting the first async clone takes some time, the second one starts quite immediately (I guess that's because the VI has already been loaded, which is no problem) After having started the VI, the VI Server ref to the VI gets closed, since it is not needed anymore.

The async VI is implemented to terminate itself when the queue reference is released. This is something, I would call standard procedure; it's also working without any problems.

But here comes the strange thing: when terminating one of the clones by releasing the queue, the Release Queue.vi executes immediately. When releasing the remaining one, the Release Queue.vi  takes about a second to execute.... independently of the Force Destroy Option setting.

I would have expected the Release Queue.vi to execute just as fast as the first one.

Can anyone explain this behaviour? I'm using LV2013SP1f5

Thanks a lot!

Oli

[JÞB]

Can you post a simplified project that we can use to reproduce this?  Otherwise we are just guessing.  My 8-Ball is good! <Darned near legendary at solving threads with less than ideal information> But, not quite up to the task you just set.

[mikeporter]

I would expect the last release to take a bit longer. Remember that you aren't creating and destroying a queue -- LabVIEW does that in the background. Hence releasing the first of two references simply tells LabVIEW to decrement a count of open references. But when you release the second reference LabVIEW is also destroying the queue.

Mike...

[Oli_Wachno]

Hi Jeff,

I'll try to strip the current version down to sth I can post. Will take me some days though

Cheers

Oli

[Oli_Wachno]

Hi Mike,

your explanation sounds quite reaseonable, but still I find 1000+ms a bit long..... so, if I want fast launch / destroy of the clones, I probably have to launch an initial dummy clone in the background whose sole  right to exist is to speed up its twins...

Gonna give it a try

Cheers

Oli

[Yamaeda]

This connects to an issue i'm also having, so i'll listen in.

/Y

[crossrulz]

---

@Oli_Wachno wrote:

The async VI is implemented to terminate itself when the queue reference is released. This is something, I would call standard procedure;

---

That should not be a standard practice.  I still have that NI has declared that a good way to stop a consumer loop.  You can lose data!  Instead, you should be sending a command of some sort to tell the consumer loop/VI to stop.

[mikeporter]

The basic point is that using this technique, you launch the VI but it stops itself when it's done.

Mike...

[Oli_Wachno]

---

@crossrulz wrote:

---

@Oli_Wachno wrote:

The async VI is implemented to terminate itself when the queue reference is released. This is something, I would call standard procedure;

---

That should not be a standard practice.  I still have that NI has declared that a good way to stop a consumer loop.  You can lose data!  Instead, you should be sending a command of some sort to tell the consumer loop/VI to stop.

---

Ok, you are right, a Stop command would be a proper way of stopping the async VIs. But in this case I can tolerate queue data being lost. Furthermore, it is required to not have any async zombies in memory if sth in the invoking VI goes wrong, so I have to implement the "Stop on invalid queue ref" anyway.

[JÞB]

Another thing to try.

In general when a "Re-enterant - Pre allocate clones" vi is first loaded into memory the clone pool is populated with one clone namespace for each processor.  The number of clones in the clone pool can be increased using the Allocate Clones method.  If you are on a single core machine this might effect the timing of the top-level vi returning to the idle state (I haven't really explored this - just guessing!) 

Other than that I'd have to wait and see your stripped down example.