Re-entrant VI: beyond the wiki basics

[torekp]

OK, so I read the Labview wiki on re-entrant VIs. And it gives a few useful examples of when to use or avoid re-entrancy. But what about everyday workhorse VIs? For example, MultiColumnSort.vi (thanks again, JFM). I use this pretty often, occasionally with large data sets, and I could easily see where two of my threads might be trying to use it simultaneously.

Should I make it re-entrant just in case? And similarly for all potentially large number-crunching operations?

What about database communication VIs? Say I've got a mid-level VI that opens a connection to an Oracle database, reads a table, and closes the connection, and I use this mid-level VI all over the place. Make it re-entrant?

In general: any good rules of thumb, not already contained in the aforementioned wiki, would be appreciated.

[Ton Plomp]

QUOTE(torekp @ Oct 9 2007, 01:40 PM)

In general: any good rules of thumb, not already contained in the aforementioned wiki, would be appreciated.

I'm no expert but as far as I know a VI with only primitives (like yours) can easily be set reentrant since there aren't subVIs that are loaded into memory.

Ton

[Grampa_of_Oliva_n_Eden]

QUOTE(tcplomp @ Oct 9 2007, 08:21 AM)

I'm no expert but as far as I know a VI with only primitives (like yours) can easily be set reentrant since there aren't subVIs that are loaded into memory.

Ton

Rules of thumb can change with the passage of time.

The "Old-Timer" in me says "Oh No!" since setting VI's that could use a lot of memory as re-entrant could result in big blocks of memory being allocated for those VI instances and becoming un-available for the rest of the application.

But now that memory no longer requires crochet hooks to build, and since people are starting to expect fast results (how long do YOU wait before you hit ctrl-alt-del?) the re-entrancy setting can help.

Just my thoughts...

Ben

[Gabi1]

quick follow up question:

i never tried reentrant with uninitialised shift register.

how to recover a specific copy of the LV2 in such case? is there any other way than keeping a reference to each vi call?

[Rolf Kalbermatter]

QUOTE(Gabi1 @ Oct 9 2007, 08:49 AM)

quick follow up question:

i never tried reentrant with uninitialised shift register.

how to recover a specific copy of the LV2 in such case? is there any other way than keeping a reference to each vi call?

Well aside from the obvious of having the VI simply in a BD and accessing that particular instance from there, no! Unlike non-reentrant VIs where the name of a VI is enough to reopen a VI reference to it, reentrant VIs maintain their data space attached to the VI instance (reference) and once you loose such a reference you loose the data space.

But then using reentrant VIs through VI Server is usually more trouble than it is worth so I personally wouldn't really do it.

Rolf Kalbermatter

[Gabi1]

QUOTE(rolfk @ Oct 9 2007, 04:03 PM)

But then using reentrant VIs through VI Server is usually more trouble than it is worth so I personally wouldn't really do it.

thanks Rolfk. do you mean you would not do reentrant LV2, and keep separate names? i kind of see an interresting recursive solution for these...altough it might not worth the trouble.

[Rolf Kalbermatter]

QUOTE(Gabi1 @ Oct 9 2007, 09:18 AM)

thanks Rolfk. do you mean you would not do reentrant LV2, and keep separate names? i kind of see an interresting recursive solution for these...altough it might not worth the trouble.

Yes I do mean that and it's because of what you mention in your last sentence. A lot of work to create something which is hard to debug, maintain and use. I have some experience with this but with templates, since reentrancy was not possible for dynamic VIs back then. And it is a pain in the ###### whenever I have to go back and change something about it and then consequently test it too.

Rolf Kalbermatter

[Michael Aivaliotis]

QUOTE(torekp @ Oct 9 2007, 04:40 AM)

Should I make it re-entrant just in case? And similarly for all potentially large number-crunching operations?

Just in case? Just in case of what? What will happen if it's not re-entrant?

QUOTE(torekp @ Oct 9 2007, 04:40 AM)

...Say I've got a mid-level VI that opens a connection to an Oracle database, reads a table, and closes the connection, and I use this mid-level VI all over the place. Make it re-entrant?

How does it work now? Is it broken? I would assume the answer is no. Everything works just fine doesn't it?

Re-entrancy is overated. In fact, it may make break a perfectly working program. Normal (non re-entrant) VI's provide Mutexing for free. Most people forget this and end up adding a lot more code to get something that a standard VI provides for free.

My rule of thumb is, don't use reentrant VI's unless you are having serious timing issues with parallel processes waiting too long to access a common VI. There are also other use case that can only be done with re-entrant VI's. For example recursion, cloned front panels etc. other uses are common subVI's used in XControls.

QUOTE(torekp @ Oct 9 2007, 04:40 AM)

In general: any good rules of thumb, not already contained in the aforementioned wiki, would be appreciated.

Reminder to all. If you participate in a forum thread and realize that something you are discussing should go on the LabVIEW Wiki, then put it in the LabVIEW Wiki. Even if it's incomplete, others will fill in the gaps.