How long will reentrant vi wait?

[Wes_Ramm1]

This is a completely academic question, but one of the things always talked about with LV2 globals is preventing race conditions. 

As I understand it, the ability to prevent race conditions is only that non-reentrant VIs will "wait" for another instance to be finished before it will execute, hence preventing concurrent access to "protected" code.  Great. 

However, in practice, how does this happen in the OS?  Will the second call of the non-reentrant VI wait for ever, etc?  Most calls should take on the order of milliseconds, so with an LV2 global, the implications are trivial, but if taken to its logical conclusion, how long will the second VI wait?  What happens to the loop where the second call is waiting? 

Wes

[Bob_Schor]

I believe the answer is that it waits until the VI in question exits.  In particular, if you put a While loop into the VI and wire "False" to the Stop terminal (so it can never exit), the second VI will "wait forever" (actually, this will probably hang your program altogether -- in the Worst Case Scenario, you'll have to log off or otherwise "force" the program to exit).

[altenbach]

I am confused by the question, because your title talks about reentrant VIs, while the body of the post talks about non-reentrant VIs.

Only once copy of a non-reentrant VI exists in memory, so if one call is in progress, the other calls to it will have to wait, possibly forever if the "other" call never finishes.

A loop cannot continue until everything it has completed. If a call stalls forever, the loop will stall forever.

What is your concern exactly?

[Wes_Ramm1]

Sorry for the confusion, I am talking about NON Reentrant vis.

No concern, as I said, just an academic question.  There have to be some consequences to the calling loops of these vi's while they are mutexing, so I'm just trying to understand the consequences.

W
 

[smercurio_fc]

As a dataflow language, LabVIEW will execute all code that is not dependent on data that is produced by the subVI if the subVI is currently being called by another process (i.e., loop). So, the direct answer is that if you have two independent loops that use the same non-reentrant subVI, and the first loops is currently calling this subVI, all code in the second loop that is connected to the non-reentrant subVI as a data source will have to wait until the call made in the first loop has completed. However, all other code in the second loop that does not depend on data from the subVI will continue to execute.