Wait on Asynchronous Call - why so long?

[smithd]

Not sure if these were mentioned elsewhere but:

• You may not be enforcing that your 'start ms' is actually your start ms since there doesnt appear to be a dataflow dependency.
• Async calls are actually a call pool, so you may have 72 refs in that array but they should be equal to one another. Meaning you really just need the ref and a count.
• If I had to guess the wait on async... is letting windows schedule other things to run which might explain why you see some of the higher peaks. You can confirm part of this by trying to make that VI subroutine priority -- it won't let you.
• You might try using the wait on async call but using a parallel for loop. I'm not sure how the wait works under the hood, so this may not do anything.

[CoastalMaineBird]

• You may not be enforcing that your 'start ms' is actually your start ms since there doesnt appear to be a dataflow dependency.

--- It's not shown, but the timed wait and the VI RefNums are in a sequence frame - there is nothing delaying the Refnums arriving, relative to that start time.

• Async calls are actually a call pool, so you may have 72 refs in that array but they should be equal to one another. Meaning you really just need the ref and a count.

--- I'm not sure why you think that - I don't think that could possibly work. If I had two calls to the same VI, I should be able to do something to one of them without doing it to the other, and if there's only one ref, that cannot happen.   In any case, I tested it and I get a different RefNum for each instance, as I would expect:

The highlighted code is added just to test this idea:

If you look at the RefNums:  

• If I had to guess the wait on async... is letting windows schedule other things to run which might explain why you see some of the higher peaks.

Maybe, but it's also true that the COLLECT process I used is waiting on them in specific order, whereas they actually quit in random order.  That would explain some of it as well.

• You can confirm part of this by trying to make that VI subroutine priority -- it won't let you.

If I try to make the block VI into subroutine priority, I get all kinds of errors about asynchronous nodes not being allowed in a subroutine (the block has an event loop of its own).

• You might try using the wait on async call but using a parallel for loop. I'm not sure how the wait works under the hood, so this may not do anything.
  

--- I tried decimating the array into four arrays of RefNums and running four FOR loops on those.  No change.

The bottom line is, I think I've gone as far as I can.  What I thought would be a more elegant solution (call and collect) turns out to have its own price.

My ORIGINAL original plan had a simple RUN VI call, and I had to SET CONTROL VALUES before that, to pass parameters into the instance.  The CALL AND FORGET is an improvement over that.  But I don't think that CALL AND COLLECT offers any benefit.

With CALL and FORGET, I can choose to do the wait or not, as necessary, without consequence.

Thanks for your thoughts.

[nathand]

---

@smithd wrote:

Not sure if these were mentioned elsewhere but:

• Async calls are actually a call pool, so you may have 72 refs in that array but they should be equal to one another. Meaning you really just need the ref and a count.

---

I think this would only be true if he'd opened a single VI ref using 0x40 + 0x80, rather than opening multiple references using only 0x80, but now you've got me curious, since I was involved in a discussion about this recently and we never considered the case where you'd use the Call&Collect or Call&Forget flags WITHOUT option 0x40. I don't have time to put together a test right now; if you come up with a definitive answer (is it a pool or not) I'd like to know.

[JÞB]

You claim  "the blocks have been commanded to die (via an event)"  Would that perhaps be a filter event?  Filter events are BLOCKING!

[nathand]

Um, it would have to be a user event, and user events can't be filter events...

[JÞB]

---

@nathand wrote:
Um, it would have to be a user event, and user events can't be filter events...

---

Say why it must be a user event.

The clones exit in order that they registered.  A Filter event should be ruled out.

[nathand]

No, the poster wrote that the clones exit in a random order (see up a few posts). "Commanded to die" meant to me that they'd been sent a command, and the only way to do that through an event is a user event, but yes, I suppose they could have all received a panel close? event or similar.

[CoastalMaineBird]

 You claim  "the blocks have been commanded to die (via an event)"  Would that perhaps be a filter event?

--- It's a user event that I created. One event is created by the container window, and fed to each block VI.

It is triggered when the user selects a menu item. Each of the 72 blocks responds whenever it can.

[CoastalMaineBird]

The clones exit in order that they registered.  

--- I'm not sure that "clones" is the correct word - these all have separate data spaces, by intent.

In any case, they do not exit in the order they registered, they exit whenever their individual event loops get around to recognizing the CLOSE event.  Since they are doing other work, that is a variable time for each instance.

[JÞB]

OK A user event.  That is a nice piece of info!

What happens if you parallize the WOAC loop?