Theory Of Operation

The basic theory behind dqGOOP is very simple, create a queue of size 1 and use it as the data store for an objects data.  The native LabVIEW queue functions match perfectly with the core GOOP functions:

Create*	Obtain Queue and Enqueue Element
Get Data	Preview Queue Element
Get Data to Modify	Dequeue Element
Set Modified Data	Enqueue Element
Delete**	Dequeue Element and Release Queue

The "Get Data to Modify" function must lock the data so no other function can access the data until the "Set Modified Data" writes the data and unlocks it.  This is accomplished automatically by using the queue since the Dequeue Element removes the data from the queue, both the Preview Queue Element and Dequeue Element functions will wait until there is data available on the queue or timeout occurs (if set).  The only way that the data becomes available is if the Enqueue Element puts it back on the queue.

Since the data is either in the queue or passed as an output of Get Data to Modify, then this "unmodified" data must be passed back to the Set Modified Data function for the case when an error can occur in a write method.  This is simplified by marking the input as "required" so it must be wired on the diagram and by providing templates that should be used to create write methods.

*The Create function can easily be separated into two separate functions, create reference and set initial data, in order to fit the GOOP inheritance models.

**The Delete function's performance could be slightly increased by removing the Dequeue Element function, however based on the very small gain in performance it was decided to leave it in.  If it is removed, the same functionality can be obtained by calling the Get Data function prior to the Delete.