LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Reentrance in ansynchronously called Vis

Solved!
Go to solution
Highlighted

Ok, This is my first attempt at trying to do this, and I'm failing miserably!!! can someone please help walk me through how to do this.  I've read the help docs and the forum posts, but none are really helping me get where i need to be.  

Basically, I have to make several Oracle database calls in an effort to reduce overall latency with a query.  We were able to get it down to 4 basic calls, which should be able to get me under the 2s mark.  but without asynchronous reentrancy, I believe the calls are just being queued and so it is taking almost 3 seconds to run them.

I've written 4 vis to make connections to our database and each executes it's own query.  However, since I'm using the database connectivity toolkit, I the sub .vis to execute the query and fetch the data are where my lag is.  I assume I need to make them reentrant, but for the life of me I cannot figure out how to do this asynchronous call thing with them being in a sub .vi... and how do I open a reference to them, as I will be throwing all of this into an executable.

In the Attachments, Get Oracle Info is calling the 4 sub.vis.

 

0 Kudos
Message 1 of 14
(748 Views)

I cannot view your VIs (I'm on LV 2016), but if you haven't already seen it, look at the examples for "Asynchronous Call and Collect" that come with LabVIEW.



CLA // LabVIEW 2016 // BALUG // Unofficial Forum Rules and Guidelines
0 Kudos
Message 2 of 14
(726 Views)

Attaching as 2016.  I tried... but I'm getting stuck because I just don't think I quite understand how to implement the asynchronous calls - esp from inside the sub.vis.  

0 Kudos
Message 3 of 14
(719 Views)

You should not be focusing on the SubVIs that execute your code. The SubVIs should run a single query and be the exact same whether you are calling them asynchronously or not. Then you use the "start asynchronous call" and "wait on asynchronous call" inside for loops, but I don't see those functions in your code yet. They show it well in the example I mentioned above.



CLA // LabVIEW 2016 // BALUG // Unofficial Forum Rules and Guidelines
0 Kudos
Message 4 of 14
(710 Views)

yeah, I think I'm just not grasping this.  I don't need for loops.  Each of the 4 sub .vis are run the execute and fetch .vis with 4 different queries (which is where my lag is), those are the 2 vi's I'm trying to get to run so they aren't being queued.  Playing around with this some more.  I've attached what I think I'm trying to do... just not sure if it is or not.  Not really seeing much improvement in my full query response time.  each of these only takes about .8s to run.  but in this configuration it's closer to 3s - indicating they are being queued. 

0 Kudos
Message 5 of 14
(697 Views)

The issue that I'm trying to solve is to get the Execute.vi and Fetch.vi to be able to run without getting queued.  I have 4 separate queries I'm trying to run, and because each of the sub .vis is using the exact same .vi, the executions and fetches are essentially getting queued.  

Maybe a better way to go about this is to just save them as Execute1, Execute2, execute3, etc.  and just use those respectively. 

0 Kudos
Message 6 of 14
(692 Views)
Solution
Accepted by topic author dbrown78
03-09-2018 11:04 AM

I'm worried that you are "barking up the wrong tree".  It seems to me that you are trying to build reentrant routines so that you can simultaneously access a Database and get the queries handled in parallel (as opposed to serially, one at a time).  Note that the easiest way to run four reentrant VIs in parallel is to simply drop four copies of the VI on your Block Diagram and ... run them in parallel!!

Simple Clones.png

Running things asynchronously just means that the VI per se does not appear on your Block Diagram, and runs independently of the calling VI.

 

So the real question is -- does your Database support simultaneous queries -- can you ask it to do four things at once and have it finish in about the same time as to do the single longest query?  If your Database can't handle parallel calls, then there is nothing to be gained by calling it in parallel, with Asynchronous Calls or not.

 

Bob Schor

 

 

Message 7 of 14
(673 Views)

You are correct.  That is exactly what I am trying to do.  However, when I run them in this configuration, they are not actually being run in parallel.  I did a bunch of digging and stumbled across this link .  Which basically describes the problem I'm having, because while the 4 .vi's I'm trying to run in parallel are unique, sub-vi's within them are shared:

  • By default, when you start multiple asynchronous calls to the same VI, LabVIEW serializes the calls, forcing them to run one at a time and leading to a longer cumulative execution time.

And that is exactly what I'm seeing.  To get around this, I ditched the asynchronous  calls and I've made my own copies (for each vi calling it) of the connection, execute query, fetch recordset vis from the database connectivity toolkit.  It did help a bit, but my connections are still getting queued.  I did some work with my database engineer, and it is definitely happening on my end, not the database side - it does support parallel/simultaneous queries/connections.  So, it seems I either need to retry this asynchronous call thing, or find another solution altogether.  I need my total response time to be under 2 seconds, and these query executions are taking 1.8-2.2s or so. (And that's without the additional overhead I'll be adding).  Any suggestions??? I'd really appreciate it. 

0 Kudos
Message 8 of 14
(632 Views)

So what you may need is for the "internal sub-VIs" to be re-entrant, allowing your four parallel routines to have their own copy of each internal sub-VI.  Note that if the sub-VIs have shift-registers inside them and use that to save a "state" between calls, you'll need to ensure there is only one such call in each of your parallel "Callers" or you'll be right back where you started.

 

Can you post one of the four parallel VIs so we (actually, I, the curious one) can get a better idea what you are doing and if it is easily parallelized?

 

Bob Schor

0 Kudos
Message 9 of 14
(628 Views)

This was my first stab at it.  I've since realized it needs some tweaks - going to need a reference for each call since I need the response from the specific call chain.  But even when running this with the wrong (out of sequence) responses getting returned I was seeing around 3s response times.  making individual copies of the vi's got that down, but I'm sure there's something here I just need to tweak to get it moving faster. 

0 Kudos
Message 10 of 14
(620 Views)