Interfaces and Reentrancy

[Quiztus2]

I am working on a HAL. Which Reentrancy would you use for abstract VI's that I define in a interface for oscilloscopes or data acquisition devices generally?

Assuming I have more than one device inheriting from IScope, acquiring data in the same test. Which Reentrancy setting would you choose? I tend to Shared clone reentrant execution.

[Yamaeda]

That sounds reasonable

[Kyle97330 · Accepted solution]

As a general rule, there's a short decision tree you can make that answers this:

Are you running on a "Real-time" operating system?  If so, use Preallocated.

Are you running code where an execution time improvement of microseconds per call will be noticeable and you have plenty of RAM and time before starting execution to allocate it?  If so, use Preallocated.

If neither of the above apply but you need to call more than one copy of the VI at a time, use Shared clone.

[Quiztus2]

It seems you cant use Preaalocated with dynamic dispatch

[tyk007]

---

@Quiztus2 wrote:

It seems you cant use Preaalocated with dynamic dispatch

---

Correct - pre-allocated means you know what VI you will be calling at compile time (static dispatch), when the whole point of dynamic dispatch is that you will only know at run-time (and thus can change behavior dynamically).

[Intaris]

---

@Quiztus2 wrote:

It seems you cant use Preaalocated with dynamic dispatch

---

Oh man, this is a discussion for another day but....

Technically, it would be possible if we could define classes to not allow run.time loading of new classes which inherit from them. Similar to a "final" or "sealed" setting from other languages. That way, the scope of the inheritance tree would be finite at compile time.

How do I know it would work? LabVIEW FPGA does it (with one extra caveat). I wish this would be possible outside of FPGA. The ease of coding with objects but the performance of inlined code..... chefs kiss....