Reference Management

DQMH modules communicate with the rest of the world via Requests and Broadcasts. Under the hood, this communication is implemented with User Events. These events are created as part of module initialization, and destroyed as part of module shutdown. The DQMH Scripting Tools maintain the scaffolding required to manage these event lifetimes.

Note: The Main VI of a DQMH module contains an Event Handling Loop, and zero or more Helper Loops, which contain event structures that are registered for the Requests of the module. You can optionally register these event structures for additional event sources, like DAQmx events, individual custom user events, or the DQMH broadcasts of other modules. In order for the DQMH scripting tools to function correctly in these more advanced scenarios, you must ensure that the Request Events cluster for the owning DQMH module is always the first element that is bundled into the cluster containing multiple event sources.

The user event references that correspond to DQMH Requests and Broadcasts are stored in functional global variable VIs. These VIs are private to the module, ensuring that the module code can access these event references when necessary, but they are not directly accessible outside the module code.

When you start a Singleton DQMH module, the module Main VI is launched via the Start Asynchronous Call function configured for a 'Call and Forget' operation. If the main VI is already running, subsequent Start Module VI calls will do nothing.

When you start a Cloneable DQMH module, an instance of the (reentrant) module Main VI is launched via the Start Asynchronous Call function configured for a 'Call and Forget' operation. One important point to note here is that a 'master reference' is opened on the first call of Start Module VI, and this master reference is leaked when the last instance of the cloneable module goes idle. This is a common approach taken in multiple asynchronous LabVIEW frameworks to improve performance when launching multiple instances of a reentrant VI. DQMH provides a mechanism to close this master reference, but it is not the recommended approach.

Note: If you are using the Desktop Execution Trace Toolkit to identify reference leaks, you can safely ignore the VI Reference leak reported for DQMH cloneable modules. This leak is only a 4-byte non-accumulating VI Reference value, and thus does not cause any performance issues.

DQMH utilizes queues to communicate between loops (EHL, MHL, and Helper Loops) within a single DQMH module. This message queue is wrapped inside of a LabVIEW class. Most of the time, this class provides all the functionality required for intra-module messaging. However, there are some times where it makes sense to create a child class of the DQMH Message Queue class, to augment or replace built-in messaging functionality. For example, the HSE Generic Networking Module utilizes this technique to allow the transparent sending of messages across a network boundary to a module running on another target.

Local Instance Events utilize Single-Element Queues under the hood to create a local data store of events for a specific running instance of a cloneable module main VI.

Notifiers are used to send payload data for Request and Wait for Reply events. They are also used as a synchronization mechanism for cloneable modules to know when the last instance of a cloneable module is shutting down.

Singleton modules utilize semaphores to ensure a module is completely shut down before it starts again. Cloneable modules utilize semaphores to ensure the Clone Registration AE functional global is locked while module instances are being added to it or removed from it.

Note: If you are using the Desktop Exection Trace Toolkit to identify reference leaks, you can safely ignore the VI Reference leak reported for DQMH singleton and cloneable modules. There is no way to know whether a semaphore is being used to lock access during module startup or module shutdown, so there is no way to know when it would make sense to destroy the semaphore. Thus, DQMH leaks semaphore references, which are only 4-byte non-accumulating reference values, and do not cause any performance issues.

Rendezvous are used to ensure that the caller of a module has registered for that module’s broadcasts before the module starts broadcasting information. Similarly, rendezvous are also used to ensure that a module has started before its caller starts sending requests to the module.