Difference with Locked Data

Should object data be locked only for writing or for both reading and writing?  The default behavior of dqGOOP is different than that of National Instrument's GOOP and OpenG's OpenGOOP.  Since the "locking" is accomplished by dequeueing the data in dqGOOP, the data is not available in the getData function so therefore, the data is locked for both reading and writing.  In most cases this difference would go unnoticed due to the "data flow" programming style of LabVIEW and the fact that the reading and writing of data doesn't occur at the same time.

However, if the need arises for a dqGOOP class to have read access to the object data while it is locked for modification, functions have been added to allow this.  These functions use a "LockedDataCache" to temporarily store the locked data while it is locked for modification.  These functions can be distinguished by the circular blue arrows in the icon .  The following table lists the default dqGOOP VIs and the equivalent ones that allow access to the locked data.

default dqGOOP	Allow read locked ()
Core functions
_getData.vi	_getData(Locked).vi
_getDataToModify.vi	_getDataToModify(StoreLocked).vi
_setModifiedData.vi	_setModifiedData(RemoveLocked).vi
Templates
_readOnlyMethod.vit	_readOnlyMethod(Locked).vit
_readWriteMethod.vit	_readWriteMethod(StoreLocked).vit
Performance Testing
_TestClassPerformance.vi	_TestClassPerformance(Locked).vi

Of course nothing is free, using the functions and templates that allow read access to the locked object data perform slower than the default functions.  See the dqClass (Locked) data on the performance chart.