GOOP VI "set modified data" locks LabVIEW for seconds

[ElvGun]

I use GOOP.
Sometimes the VI "set modified data" (from now on SMD) of one of my GOOP classes is locked for about 15 seconds, while CPU raises to 100%.
It happens when SMD is called from a certain VI. It does not happen every time SMD is called from this VI.

As I have understood GOOP, the VI "get data to modify" tries to access/lock the data members - which might take a while if the the data members are currently locked by another VI - but SMD only sets the data members and removes the lock, which should always be possible (at least if the data set has been locked by this VI, which - yes! - is the case).

Other VIs are running in parallell, maybe they could cause the CPU to raise to 100% but I find it strange th
at it only happens when SMD is called from this particular VI.

I think I need a better understanding for how SMD really works.

Regards

[Mattias_Ericsson]

Hi,

Your description of how "get data to modify" (from now on called GDM) and "set modified data" works is correct and you have fully understand how it all works. The only VI that actually may wait is the "get data to modify" (happens if the data for the object is locked by something running in parallell as you describe). The GDM is however reentrant so that it really will be able to wait for seconds (specified by the timeout) and also letting other process wait as well using the GDM. The SDM is not reentrant (does not have to) and should really execute fast (set data and unlock) and never hold execution, just as you describe.

Are you absolutly sure that it is the SMD that cause the CPU to freak out? Maybe the fact that you unlock the data releases ano
ther part of your program that were "hanging on the lock" and the problem is actually in another part of the program. Do you have some exceptional large size of your data? Do you somehow elaborate with VI priorities and/or reentrant VIs. This might sometimes really cause strange situations. The situation you describe looks more like a "race" problem.

The SDM problem you describe is new to me and I have never encounted it. Would it be possible for you to attach some LV code example showing the phenomenon?

Best regards,
Mattias Ericsson
Endevo Sweden
(member of the GOOP developer team)