LabVIEW native functions - reentrant or not?

[pelaid1]

Are LabVIEW native functions treated as reentrant or non-reentrant? This would be with respect to Queue Operations (Enqueue Element, Flush Queue, etc.)

[zou]

All functions with yellow icon are reentrant.

[crossrulz]

---

@pelaid1 wrote:

Are LabVIEW native functions treated as reentrant or non-reentrant? This would be with respect to Queue Operations (Enqueue Element, Flush Queue, etc.)

---

A very large majority of my projects would not work if they were no reentrant.  As already said, all of the primitives (yellow nodes) are reentrant.

[Ben]

---

@crossrulz wrote:

---

@pelaid1 wrote:

Are LabVIEW native functions treated as reentrant or non-reentrant? This would be with respect to Queue Operations (Enqueue Element, Flush Queue, etc.)

---

A very large majority of my projects would not work if they were no reentrant.  As already said, all of the primitives (yellow nodes) are reentrant.

---

While for the most part yes but for some reason I think there is some very low-level something that is used by the queue functions that is special.

The term "atomic" comes to mind but I'd be darned if I can recall what the story that goes with that memory.

To the original poster of this question...

What prompts you to ask?

Ben

[pelaid1]

Ben,

Thanks for the info. I'm currently working on an application that runs on a test system for a medical device manufacturer. This test system uses 2 - NI PXI-7811R FPGA cards to service 12 test insertions at one time. Therefore, 6 instances of the application will use FPGA card #1 and the other 6 instances will use FPGA card #2. The way the application is structured, most of the upper level VIs are reentrant, but the lower level VIs that interface with the FPGA cards are non-reentrant. A semaphore is used to handle the queue for the FPGA card.

I'm picking up the code where others have left off, and am reviewing for proper reentrancy settings. I encountered an issue where an upper level VI is reentrant, a sub-vi called from there is non-reentrant, and the native LabVIEW functions the sub-vi calls are apparently reentrant. This seems like bad coding practices to me - I believe there should be a point at which it should transition from reentrant to non-reentrant, but not switch back and forth.

Sorry for the long drawn out response, but that's why I asked....;-)

[pelaid1]

Also, does anyone know of a users guideline for reentrancy settings?? Thanks!

[billko]

---

@pelaid1 wrote:

Ben,

Thanks for the info. I'm currently working on an application that runs on a test system for a medical device manufacturer. This test system uses 2 - NI PXI-7811R FPGA cards to service 12 test insertions at one time. Therefore, 6 instances of the application will use FPGA card #1 and the other 6 instances will use FPGA card #2. The way the application is structured, most of the upper level VIs are reentrant, but the lower level VIs that interface with the FPGA cards are non-reentrant. A semaphore is used to handle the queue for the FPGA card.

I'm picking up the code where others have left off, and am reviewing for proper reentrancy settings. I encountered an issue where an upper level VI is reentrant, a sub-vi called from there is non-reentrant, and the native LabVIEW functions the sub-vi calls are apparently reentrant. This seems like bad coding practices to me - I believe there should be a point at which it should transition from reentrant to non-reentrant, but not switch back and forth.

Sorry for the long drawn out response, but that's why I asked....;-)

---

I'm not sure what you mean by "switching back and forth".  It seems to me that it is very well defined.  Stuff you make is non-reentrant by default, while native LabVIEW nodes are reentrant.  I do understand that it is frustrating that just one non-reentrant thingy in your reentrant VI suddenly makes the VI behave unexpectedly (but adhering to dataflow principles), though.