03-26-2018 04:26 AM
Hey,
I am just trying to update my knowledge concerning FGVs and thus I stumbled upon an alternative using DVRs (data value references).
Manipulation would then take place with Inplace elements, using the data value reference and manipulating it.
My scope is to find a way to manipulate a "bigger" cluster without race conditions. If I use FGVs to avoid the race conditions I would have to add a terminal for each cluster element I would like to manipulate. That could mean quite a lot of terminals if you have a e.g. a cluster with 10 elements.
Now the DVRs look quite nice as an alternative. The only question I have is: is the inplace element structure insensitive to race conditions?
If e.g. Element 1 is opened by the first inplace element struct and is now in the middle of modification, is it possible for the second inplace element structure to already read the (currently still unmodified) data? That would then in my opinion lead to a race condition.
In the attachment you find a simple example vi of the way I would like to use it.
Unfortunately I lack in generating a test vi to securely verify if there is a race condition or not (->Monday morning?).
Maybe some of you guys have experience with DVRs and can help me out.
Solved! Go to Solution.
03-26-2018 04:38 AM - edited 03-26-2018 04:38 AM
IIRC, the operations as I see them on your BD should each be essentially atomic, completed without and side-effects and free of race conditions. If one IPE is already doing something, the others need to wait before they can gain access to the DVR. However, once you create a dependency between two individual IPEs (Like reading a string in IPE 1, doing something else and then writing a modified string back in IPE 2) then you're back in race condition territory.
Just make sure your operations are completely contained within a single IPE and they should be fine with regard to race conditions.
03-26-2018 04:40 AM
Thanks for the fast response! That is great news. That would simplify data handling very much. I am just trying to create an example to test the race conditions. Once finished, I will upload it and hopefully verify that.
Thanks again!
03-26-2018 04:48 AM
Ok, test is done. In the attachment you find a vi that contains a cluster with multiple elements, starting two inplace elements that each manipulate an individual cluster element. The first IPE contains a waittime of 1500 ms whereas the second IPE starts after 500 ms. In case of race conditions, the result should not contain both modified values.
But in fact just as Intaris suggested, both values remain and thus there is no race condition.
Thanks!
03-26-2018 06:38 AM
Since you are investigating race conditions, you might want to give this a good look: A Look At Race Conditions. What I found doing that article and my NI Week presentation was that Action Engines are great for smaller data sets, where DVRs are great for large data sets.
03-27-2018 02:36 AM
Dear crossrulz,
thanks for this link. That is gorgeous. The sum or mean value was the token I was looking for. That way it is really easy to judge whether there are race conditions or not.
Thank you very much for the idea, now I can build up my own performance tester!
Best Regards
Jensolo