Can I lock access to vi's using embedded but inactive copies of those vi's?

[heel]

The aim is to avoid race conditions between different vi's. A representative example is this:

Will this vi reserve the vi's in the non-executing case structure? In reality the true case (shown above) will never be able to run, because the case is always false and the compiler could safely decide to remove them entirely.

Does it remove non used vi's?

I have read that this trick with embedding into non-active case structures is useful when using dynamic loading of vi's. Doing like this you are sure they are in the dependency path and will be included when making a distribution.

[crossrulz · Accepted solution]

Around the 8.0 days, that trick stopped working.  The compiler got smart enough to remove those cases.  The even more modern compiler will totally remove the case structure, and likely the Merge Errors as well (replaced with just a wire to the Error Out from your other subVI).

What exactly are you trying to accomplish?

[mikeporter · Accepted solution]

If I understand you, yes. The compiler will optimize the case statement out of existance. This is why a few versions ago when LV updated code it converted all constants being used in this way into hidden controls. Controls could theoretically be changed at runtime so using a hidden control instead of a constant would retain the previous functionality.

But what does any of this have to do with race conditions?

Mike...

[heel]

Thanks for swift and clear replies.

My specific problem is: To flush a message queue and put a message at the front, when realizing that this is not safe as someone may post messages between the flush and posting at the front.

So as to Mike Porters question: The race condition is because the vi's share a common resource - in my application a queue.

I conclude from Mikes suggestion that the following should work as intended:

= The true - but inactive - case will be retained by the compiler.

[crossrulz]

An Action Engine would probably be the cleaner (and more reliable) way to do what you want.

[heel]

I think crossrulz is right. It is unsafe. Who knows what LabVIEW2013++ will do with such code.

Thanks. I'm on my way with that.

Maybe could someone comment on this side-note which happend to show up - to wrap up things brought up here:

..this trick with embedding into non-active case structures is useful when using dynamic loading of vi's. Doing like this you are sure they are in the dependency path and will be included when making a distribution.

also in this case, is it safer to use a control and not a constant, or are there better ways to automate dependency maintenance?

[crossrulz]

---

heel wrote:

Maybe could someone comment on this side-note which happend to show up - to wrap up things brought up here:

..this trick with embedding into non-active case structures is useful when using dynamic loading of vi's. Doing like this you are sure they are in the dependency path and will be included when making a distribution.

also in this case, is it safer to use a control and not a constant, or are there better ways to automate dependency maintenance?

---

Ah, the dynamically calling of VIs.  When you dynamically call a VI, LabVIEW can't tell what VI you are going to call.  So the VIs that you want to call dynamically were not put into the executable build.  Then you have errors (VI not available).  So the trick a long time ago was to put VIs that you want to call dynamically into a case structure that would not run.  LabVIEW would see the VI and put it in the built executable.  This is the main reason when you convert from 7.1 or older to 8.0 or newer, you see the constants changed to hidden controls.

So what is the best way to do this now?  In the build specification of your executable there is an "Always Include" section.  Put your dynamically called VIs in there.

[mikeporter]

Alternately, you can also create a static reference to the VI. That will also ensure that it is included.

Mike...

[A.E.M]

Just want to confirm, that you are correct about the compiler. Nowadays the compiler will optimize your code, so that the execution time will speed up. It does so, by remove code we're not using- called Dead Code Elimination. You can read more about it in the following article:

NI LabVIEW Compiler: Under the Hood

I also agree that a good way of protecting critical sections is by using a Function Global. Another way is to use a Semaphore, which might be more easy to relate to for some, especially if they are already familiar with other programming languages.