Storing DVR reference

[MartinMcD]

Hello,

I need to share some data between parts of the program that can't be wired together.  I know there are lots of ways of doing this: uninitialised shift registers, single-element queues, globals, DVRs etc.

Assuming I'm going to use a DVR because the blocking action of the In Place Element Structure helps with race conditions and so on, and assuming my architecture is fixed so I can't wire the DVR around, then I still need to provide access to that reference.  Is there a relative benefit of storing it in a private class global/SEQ/uninitialised shift register etc or are they all as good/bad as each other?

Thanks,

Martin

[DFGray]

If you cannot wire the reference around, your best bet is to use a global to access the DVR reference.  You will need a boolean or similar mechanism in the global, as well, to signal when initialization of the reference is complete.  You may want to encapsulate access to the reference into a class to make things easier to do correctly, but there is no getting around the fact that the global will make your DVR reference accessible at any time, and this could easily lead to race conditions in the calling code when someone who is not you writes things.  Design carefully.

A better option is to use a named single-element queue.  You end up with virtually the same semantics as the DVR, and the same effective locking, but you can acquire it anywhere by name.  Make sure the name is unique.  You can encapsulate access to the named single-element queue in a class, as well.  I would recommend this option.

As you mentioned, you really need to refactor the code so you don't need these kinds of workarounds.  Good luck!  Let us know if you need more info.

[Mark_Yedinak]

I would use a singleton class to encapsulate the DVR. It provides clear access to it throughout your code. The named SEQ will still need error processing to ensure it is initialized. In addition I an fairly sure that DVRs provide better performance.

[DFGray]

Mark, the implementations of singleton classes I have seen use either single-element queues or DVRs to provide the singleton functionality.  This could be a solution, with the data put into the class, but I am not sure it solves the problem of no reference.  If you create an acquire function for the named single-element queue, and always use it, you don't have the problem and there is no issue with initialization.  Every location which acquires the queue reference gets a valid reference to the queue.  If a location acquires the reference to dequeue it, it will wait at the dequeue until the initialization location has initialized the queue and there is something to dequeue.  The key is to create the acquire VI which initializes a single-element queue and always use it, not the bare queue primitives.

You are correct that a DVR is faster than an SEQ, but the difference is pretty small.  I suspect the encapsulation needed for the DVR would make it somewhat less efficient, assuming each access of the SEQ did not also require an acquire queue ref operation.